http://bugs.winehq.org/show_bug.cgi?id=14717
--- Comment #177 from Andrew Eikum aeikum@codeweavers.com 2011-10-19 08:40:01 CDT --- (In reply to comment #176)
Here Raymond is right, even if he doesn't know what he is talking about. I recommend not basing your work on the patch in this bug or on my not-yet-published patchset, because it is based on the same idea of adding a resampler to wine.
Indeed, no resampler is needed in wine, and no software mixing layer, either. This is the job of the underlying platform such as ALSA. Any desktop audio platform that doesn't provide these capabilities is nowadays considered broken, or can be augmented with pulseaudio or ESD, and thus wine should not cater for it. Yes, this will kill direct output to "hw:X" ALSA devices.
I'm unconvinced. What you're describing here is activating an IAudioClient for every secondary buffer (or primary buffer in primarywrite mode), and letting the driver backends take care of mixing the AudioClients' buffers together. I don't think that would work.
Some applications use a lot of secondary buffers to store their sound effects, and call Play() on each of those to play the effects. For these applications, you'd be creating a whole bunch of IAudioClients. In ALSA+PA and OSS, this effectively creates a ton of virtual devices, each with its own set of controls in the mixer panel. FreeBSD's standard OSS settings limit each device to 16 virtual devices, which is actually quite few. Creating devices only as they are Play()ed is impractical due to latency problems.
There's also the issue of 3D sound support, which isn't available through MMDevAPI, and would require its own mixing anyway, in some form. This is a smaller concern since we don't support 3D audio now anyway.
On top of this, dsound is really fragile and I hesitate to make any large changes like that to it, if isn't not clearly the correct thing to do.
As much as I dislike it as well, I'm not sure we can avoid having a mixer in dsound.