[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 #45 from Jörg Höhle <hoehle at users.sourceforge.net> 2011-11-11 17:16:32 CST ---
>I can't find where in the comment #19 I had been talking about 100% prefill
>(you're considering 30ms duration / 10ms period case, right?).
No. I was considering a 10ms period and a 40ms buffer filled 3/4 = 30ms you
mentioned in comment #24 even though that requires a period >= 10.5ms as you
explain in comment #19.

>Data that had been received through GetBuffer()/ReleaseBuffer() calls might
>be immediately pumped out to ALSA. Jörg, you had
>mentioned that there are some constraints against acting in a such way

When you pump out data at fixed intervals, you can reason about the properties
of your system:
- if ALSA has less than mmdev_period samples after my write, there'll be an
underrun.
- if ALSA has not started yet and I write less than alsa_period samples,
   then it may not start -- bug #29056 -- so I must fill it up, which should be
safe,
   as the app did not write more data in this (mmdev) period.
- Get/ReleaseBuffer is presumably a fast operation in native, so the app never
blocks.
   ReleaseBuffer used to wait while writing to OSS, see bug #28056, comment
#35.
- Several threads writing to the same ALSA stream, hmm...
- You can even add code to detect that sound hung during the last events and
reinitialize it.

If you write data anytime, you can't decide anything because you don't know
whether the app may call Get/ReleaseBuffer again within the next millisecond.
Yet I think that a heuristic like "if near underrun, feed ALSA a little" may be
ok, nevertheless one must carefully assess how this affects GetCurrentPadding,
as your analysis shows, and how to solve bug #29056, i.e. when to pad with
silence.

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