[Bug 28723] Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound output path)

[wine-bugs at winehq.org]

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

--- Comment #51 from Jörg Höhle <hoehle at 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.

-- 
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.