http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #57 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-12 06:34:26 CDT ---
Actually, the 3-4 period limit has nothing to do with PA. [...]
Your explanation is correct except for one point.
We *could* use snd_pcm_drop, however it would introduce observable behaviour different from native and I've written the tests in Wine to catch that deviation. Namely, the effect upon GetCurrentPadding (lost frames).
I believe we'll have to re-evaluate that decision some day. The drawback of the 3-4 periods limit is bug #29531 and such. Audio currently very much depends on Linux always waking up our threads often enough within this 30ms limit. There's no guarantee for that! The log in that other bug looks like there was a 100ms delay out of the blue.
You can bet that native's audio engine has one of the highest priorities. Maarten is right to beg for real-time priorities, although I don't see that happen for Wine (I too consider RT too dangerous in Wine). So we need to find ways to buffer much more.
So in principie, we may have to decide to agree to let some tests fail (well, change them), let GetCurrentPadding decrease much more than native's at the benefit of allowing the audio driver to buffer much more than meager 30-40ms.
The pre-1.3.25 winmm drivers used much larger buffers (as large as the application provided, e.g. 333ms from our MCIWAVE device) and hence did not suffer from jitter or scheduler arbitrations.
OTOH, Wine's dsound has always used 10ms periods. I've not analysed how much data the old driver sent to the ALSA/OSS driver in advance.
And we've not yet analysed in sufficient depth what else we can do on the Wine side to help the Linux scheduler call our audio driver very often. Too many critical sections? Too many thread convoys?
The only advice I found to maintain a high rank in Linux scheduler's priority is: "do your little work fast, then wait/sleep".