Relax test requirements to accomodate fuzz of msacm

[Robert Reif]

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.