http://bugs.winehq.org/show_bug.cgi?id=28748
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |14717
--- Comment #1 from Andrew Eikum aeikum@codeweavers.com 2011-10-18 14:08:52 CDT --- This is caused by the resampler mess in dsound. If you set the registry to have dsound use a 48khz sample rate (which matches the application's audio rate, meaning no resampling is necessary), the audio does work.
The trouble is that Wine chooses to resample the application's buffer in the client thread during the secondary buffer Unlock() call, and not in the mixer thread. I assume this is to try to prevent underruns due to the CPU intensity of resampling (commit 3aeedea0b646a0b6a783a67069bedf00ce0131c8 introduced this behavior). But, the application continually modifies the data in the buffer without using Lock() or Unlock(), so the data written by the application never gets resampled. dsound just continually sends the first Unlock()'s resampled data, which happens to be silent, to mmdevapi.
The solution, I think, is to always do resampling just before sending data to mmdevapi, which basically involves moving it /back/ into the mixer thread, undoing the commit mentioned above. But before we do that, we should get a more efficient and high quality resampler, which is Bug 14717. I suspect this bug will be fixed when Bug 14717 is fixed, due to the amount of related code that will be touched.