http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #10 from Andrew Eikum aeikum@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".