IsFormatSupported tests & compatibility affects winmm's acceptable formats

Hi,

Apps that use WINMM are best served when the default sound card is
a (pseudo-)device that supports all kinds of formats and rates that the
app may throw at it (even 9123 samples/s). Resampling in the OS (e.g.
ALSA plug pseudo-device) is preferable as that code is well maintained,
whereas Wine's resamplers (dsound and msacm) are known for
poor quality (bug #14717).

It would not be wise to present a sound card that accepts only 48000 to
the w95 era application.  22050 is (was?) the standard, and even
winmm/tests/wave.c expects that rate (a bug in wave.c).

However, testing mmdevapi:IsFormatSupported shows that native solely
accepts a single rate and fixed number of channels (e.g. 48000 stereo),
whereas Wine's accepts almost any standard PCM format. Wine's new
winmm relies on mmdevapi to support all sorts of formats. BTW, native's
w7 winmm accepts all formats too.
As a result, Wine's winmm would not work with a native mmdevapi!
In other words, native has a much more elaborate
winmm->mmdevapi bridge than Wine currently does.

So either Wine's IsFormatSupported is kept incompatible because Wine's
winmm needs it, or the behaviour of IsFormatSupported is aligned with
native's, requiring unforeseen changes to the current codebase.

Here are the results of my experiments with test bot over the week
end.  Note that I've only tested SHARED mode and standard formats
8000 x 1|2 x 8|16 WAVE_FORMAT_PCM or EXTENSIBLE PCM.

- Like MSDN documents, IsFormatSupported sets ClosestMatch if and only
  when it returns S_FALSE.  WineALSA has a bug here
  (that confirms my partial patch from last week).

- pClosestMatch looks like what GetMixFormat returns.
  E.g. IsFormatSupported(8000x1x8UINT) will suggest 48000x2x32FP.
  I've not tested with #channels >2.

- IsFormatSupported S_FALSE => Initialize AUDCLNT_E_UNSUPPORTED_FORMAT.
  So S_FALSE does in no way mean "it's not my favourite, but I'd do it anyway".

- Presumably a bug in native: after UNSUPP_FORMAT from Initialize,
  another call with a format that should work yields
  ALREADY_INITIALIZED.

- Except for 48000x2x16 and 48000x2x8, all standard PCM formats I
  tested yield S_FALSE, i.e. they are rejected.  That means that the
  native mixer accepts integer formats at its nominal rate (48000),
  but does not even convert mono to stereo.

- AUDCLNT_STREAMFLAGS_RATEADJUST is not documented by MSDN
  http://msdn.microsoft.com/en-us/library/dd370791%28v=VS.85%29.aspx
  RATEADJUST causes the win7 and most w2k8 test bots to Initialize
  succesfully when suplying a rate != GetMixFormat.  However
  48000x1x16 (mono instead of stereo) is still refused!  Google found
  one single app that uses that flag and the associated SetRate interface.

Note that SetRate does not help with mono->stereo which is still refused.

Regards,
        Jörg Höhle

IsFormatSupported tests & compatibility affects winmm's acceptable formats

[Chris Robinson]

On Thursday, August 04, 2011 12:55:51 PM [e-mail] 
wrote:
> - Except for 48000x2x16 and 48000x2x8, all standard PCM formats I
> tested yield S_FALSE, i.e. they are rejected.  That means that the
> native mixer accepts integer formats at its nominal rate (48000),
> but does not even convert mono to stereo.

MMDevAPI does not normally remix channels or do rate conversions, according to 
MSDN:

http://msdn.microsoft.com/en-us/library/dd370811(v=vs.85).aspx
"An application that uses WASAPI to manage shared-mode streams can rely on the 
audio engine to perform only limited format conversions. The audio engine can 
convert between a standard PCM sample size used by the application and the 
floating-point samples that the engine uses for its internal processing. 
However, the format for an application stream typically must have the same 
number of channels and the same sample rate as the stream format used by the 
device."

However, it is possible to circumvent that:

http://msdn.microsoft.com/en-us/library/dd370876(v=vs.85).aspx
"The audio engine might be able to support an even wider range of shared-mode 
formats if the installation package for the audio device includes a local 
effects (LFX) audio processing object (APO) that can handle format 
conversions."

I don't know how visible APOs are to applications, but accepting multiple 
channel formats and sample rates isn't technically a problem. It's just not 
something typically done.