Jeremy White wrote:
So the only fix I can imagine would be to not use msacm to perform these conversions and have a parallel set of converters do this in an aligned fashion.
This would probably be the best way for wine. Keep the existing wave mapper code and just add a better converter specifically for this case. Msacm uses the absolute worst possible algorithm that will get the job done so keeping it for compatibility and adding a better one for the wave mapper is a reasonable solution.
But, again, I wonder if Windows doesn't have this exact same behavior but we can never find it because all Windows hardware drivers claim direct support for all of the winmm formats, so Windows never does a software conversion.
Windows 2000 and xp sound systems have a software mixer called kmixer which will convert any and all application output to the format supported by the hardware. Because of this, some newer systems only support 48kHz 16 bit stereo in hardware and rely on kmixer to do the conversions. This is also why the cooperative level settings in direct sound are no longer needed because kmixer lets the application think it has exclusive access to the sound card and that it supports the requested format.
In windows 9x an application has direct and exclusive access to the sound card. Thats the reason for the cooperative levels in direct sound. The wave api gives you the option of using formats only supported by the hardware or using the wave mapper to do the format conversions in software for you. I don't have access to a win9x machine to verify this but my guess is that either mascm is not used for PCM conversions or that it does something extra to deal with it's limitations.
The tests pass on windows so fudging the tests to work around a bug in wine is not the best solution to the problem.