http://bugs.winehq.org/show_bug.cgi?id=30639 --- Comment #2 from Andrew Eikum <aeikum(a)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:
1) 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.
2) 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.
3) 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
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.
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). -- 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.