[Bug 29585] wineoss.drv audio renderer not on par with others

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Jan 20 14:12:08 CST 2012


http://bugs.winehq.org/show_bug.cgi?id=29585

--- Comment #1 from Andrew Eikum <aeikum at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list