http://bugs.winehq.org/show_bug.cgi?id=29585
--- Comment #1 from Andrew Eikum aeikum@codeweavers.com 2012-01-20 14:12:08 CST --- Created attachment 38468 --> http://bugs.winehq.org/attachment.cgi?id=38468 BROKEN: Patchset to improve wineoss
Here's two patches that improve the OSS driver, similar to how you suggested. The first patch fixes GetPosition (it's basically the same patch as on the mail you link, but with your bugs fixed). The second patch duplicates winealsa's buffering behavior. Even though it passes your extended render tests, it's not quite correct.
I'm going bonkers trying to figure this out, so I'm posting it here for now.
The strategy is to limit the amount of data that we actually send to OSS, since OSS has no mechanism to pause playback. So, we try to keep no more than 4 periods' worth of data in the OSS buffer, and retain the rest in the MMDevAPI object. This is just like winealsa. BUT we can't actually get a reading on how much data is in the OSS buffer, because of the following annoyance.
The GETOSPACE call seems like it should work. It gives us the fragment count (bi.fragstotal), the fragment size (bi.fragsize), and the amount of space available to write (bi.bytes). So (bi.fragstotal * bi.fragsize - bi.bytes) should give us the amount of data residing in the OSS buffer. But of course it's broken. After creation (i.e. without write()ing anything), on my computer, I found that bi.fragstotal * bi.fragsize > bi.bytes, so that calculation yields data sitting in the OSS buffer, even though we haven't written anything. Wonderful.
There is another call, CURRENT_OPTR, which explicitly returns "the number of samples currently buffered in the device level FIFO." But, it never succeeds for me. I always get EINVAL, which is usually interpreted as "invalid ioctl command." The support for this call appears to be ifdef'd out if the "long long" type isn't supported. Even though "long long" is supported, I removed those ifdefs, recompiled, and it still fails with EINVAL. So I have no clue why that call isn't working. Again, wonderful.
So I'm just going to leave this here for now and come back to it later. Argh.