[Bug 30836] Total Overdose: choppy audio playback with Diesel Power 3D sound system

[wine-bugs at winehq.org]

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

--- Comment #10 from Andrew Eikum <aeikum at codeweavers.com> 2012-10-10 13:29:56 CDT ---
I haven't figured out TOD's algorithm for writing more audio data. It holds the
_Lock()ed buffer and polls IDirectSoundBuffer::GetCurrentPosition() rapidly. It
seems to trigger an _Unlock()-_Lock() cycle when GetCurrentPosition's
PlayCursor parameter changes. But if you hack PlayCursor to never change, then
it does those cycles anyway, often in rapid succession.

At some level, there are two timers that TOD depends on being in sync. One is
the timer that controls GetCurrentPosition()'s PlayCursor, and the other is its
own internal clock. When they get out of sync, TOD seems to assume that the
entire buffer has been played and proceeds to write the entire next buffer, so
you get the choppy, too-fast audio that this bug describes.

The patch that caused the regression changed how dsound depends on the audio
driver's timing. It sometimes takes more than a period for the ALSA driver to
update its IAudioClient::GetCurrentPadding(). That means the PlayCursor now
takes too long to change, and falls out of sync with how TOD expects it to be
have, so it assumes the whole buffer has been played, and skips ahead in its
audio.

I'm working on changes to how winealsa times its writes to ALSA to play more
nicely with a PulseAudio backend. I tested TOD with my preliminary patch, and
it actually fixes the timing issue, causing TOD to work correctly again. If you
want to test an early version of the patch, you can find it on Bug 28622,
"winealsa.drv: Feed data at a fixed rate".

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