http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #51 from Jörg Höhle hoehle@users.sourceforge.net 2011-11-24 19:51:15 CST --- Given what Alexey explained about 20ms bufer sizes, I'm convinced that -- which is easy to test -- after the first event callback, padding will have decreased by 10ms.
Second I'm convinced that, given Linux scheduler's properties (esp. CFQ), it would do no good to audio to insist on 10ms wake-up periods. Wine does not use soft real-time OS features. Instead the audio driver should really be written in such way that if it's fed more audio data, e.g. 333ms, it won't depend on a wake-up every 10ms. AFAIK, PA uses 50ms periods. A Linux user thead is somehow at the opposite of a real time thread: all root threads lie in between.
IOW, I'm opposed to a design that depends on 10ms feeder threads just because that would make Rage (or any 20ms XA2 client) work. XA2 ought to work, yet other apps with large buffer sizes must not stress the system ^H^H produce reliable audio output even if a 10ms event is missed. The general lesson is that I can't expect a Linux system to give repeated 10ms "interrupt" response. There will be random (=rare) cases with higher latency (upto 100 ms with user processes).
I also think that it would be very revealing to write the following test case: on every (10ms) event, feed 5ms of data. I conjecture (based on GetCurrentPadding's return value after underruns) that w7 will beep 100 times a second, while older systems (Vista) may well coalesce data until a full 10ms is full before sending it to the audio device, thus beeping 50 times a second. Obviously, such a test should be performed by somebody with access to both systems. I have none of them.