http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #1 from Alexander E. Patrakov patrakov@gmail.com 2012-05-10 13:05:31 CDT --- This slowdown is an expected consequence of using a high-quality (i.e. same quality as Widows XP) resampler. Your CPU is just not fast enough to resample that many concurrent audio streams from the sample rate used by the game to the default output sample rate used by Wine.
Some suggestions:
1) Recompile dlls/dsound with -O3 -ffast-math -msse3 in CFLAGS. This alone should give a 2x speedup to the resampler.
2) Avoid resmpling if possible - that's what Windows does. To achieve this, open Regedit and create the HKCU\Software\Wine\DirectSound\DefaultSampleRate registry string value. Try putting 44100 and 48000 in it. With the value that matches the sample rate of the game's sounds, the CPU usage will return to its old value below 100%.
I.e. there are the following possible improvements in Wine without sacrificing sound quality:
1) Group secondary buffers by sample rate. Mix each group separately, resample only the result, then mix the result of resampling.
2) Return a non-zero CPU cost of mixing, in hope that an application will create less streams to mix.
3) Use SSE
4) Try to imitate the Windows way of selecting the primary buffer sample rate more thoroughly (I.e. I guess that the default sample rate should not exist). If that fails and the app didn't set an explicit rate, just set it to the sample rate of the first secondary buffer, even though this violates the spec.
(2) and (3) are low-hanging fruit, (4) may be possible, but (1) requires more refactoring that I am able to do.