I think the flaw goes like this:
1) whatever the intention of the sound app, the audio device driver will always be requested with some "dummy" sound format (sample rate, num channels, bit depth) and to perform audio playback (and not record). The audio device driver is supposed to acknowledge the choice or give the next best alternative. Idiotic enough, the sound apps requirement will ultimatively be communicated to the sound driver once a stream is opened (for playback or recording), no matter what the device driver reported to this initial check request.
2) if the audio device driver cannot acknowledge the requested sound format, this will be ignored for the most part. But if it does not acknowledge the "playback" but instead reports that it can only do "record", then this is not ignored and the audio driver will never be opened with a stream.
Wim, I think not the audio device drivers need a fix but we rather need to add a hack to USBAUDIF.DLL to fake the caller of USBAUDIF.DLL that "playback" or at least "playback or record" was acknowledged instead of "record only". In the end, the caller will overrule this reporting anyway and will subsequently open the stream it needs (playback or record, whatever is intended by the sound app). The drawback of this solution is obvious: if a sound app requests playback but the device really is "record only", this will of course fail if the stream is finally created. However, the audio device drivers properly handle this error, and therefore, at least nothing will crash or break. You will just get an error in the sound app (which might be confusing if everything seemed to work initially).
This is all due to the lousy implementation of the multimedia subsystem as a whole. It's a mess.
