http://bugs.winehq.org/show_bug.cgi?id=30639
--- Comment #2 from Andrew Eikum aeikum@codeweavers.com 2012-05-10 13:26:57 CDT --- (In reply to comment #1)
I.e. there are the following possible improvements in Wine without sacrificing sound quality:
- Group secondary buffers by sample rate. Mix each group separately, resample
only the result, then mix the result of resampling.
This is a good idea, and shouldn't be too hard. I'll give it a close look, though it will have to wait until after the rest of my cleanup patches are in.
- Return a non-zero CPU cost of mixing, in hope that an application will
create less streams to mix.
I'd be very surprised if there were more than one or two applications that actually use that parameter. Not a bad idea on principle, but I doubt it will help.
- Recompile dlls/dsound with -O3 -ffast-math -msse3 in CFLAGS.
Strikes me as a good idea. Are you still planning to work on this, Alexander? I'd be interested to hear results from GyB if these flags improve things
- 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.
This is worth experimenting with, but creating heuristics that work well is always tricky (e.g. which rate to choose, what to do if the preferred rate changes while playing, etc).