http://bugs.winehq.org/show_bug.cgi?id=27956
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #21 from Jörg Höhle hoehle@users.sourceforge.net 2011-09-21 15:21:30 CDT --- I would not be opposed to an msacm chain. Not of any length, but to accommodate PCM formats. I'm not sure native would not daisy chain converters if really needed - otherwise the PCM rate converter in msacm is probably never used.
The current code produces surprising results: Given the msacm resampler, the wave mapper will accept any PCM rate, but ADPCM only at the rate supported by the HW. This is not round.
Back in the old days, probably every card would accept mono.
In the modern mmdevapi days, note how native winmm:wave tests report "all WINMM formats supported" (formats=fffff) whereas my mmdeapi:render format tests reports that AudioClient:IsFormatSupported solely supports 44100 and 48000 16bit stereo (in exclusive mode, which presumably reveals what the HW really can), which is typical of modern cards.
Obviously, Vista-w7 close the gap and provide both resampling, channel and bit width conversion to winmm.
Wine behaves differently and relies on the underlying ALSA/OSS/CoreAudio to close the gap beside what msacm can do. This works on my machine with the default device that is either plug:dmix or PulseAudio which can support mono, but the individual hw:0 device can't. plughw:0 can.
Wine should strive for more HW independence and provide the same user experience on all machines.
so that every device supports both stereo and mono sound
Native doen't seem to do that at the mmdevapi (IsFormatSupported) level, yet the past Vista winmm rewrite supports all formats, mono or stereo. Native mmdevapi is documented to accept and convert 8/16 bit (verified by my tests).
Susan, can you trick the registry so as to use plughw:x,y as your device instead of the raw hw:x,y? The plug ALSA thing will do channel "mapping". Are you telling the app to use one of the enumerated & named devices or does it simply use "default" / device -1 or 0?
Maybe winealsa should use plughw instead of hw for the enumerated devices? What does OSS allow?
What I don't yet understand is: why was there a change with wine-1.3.25? The winmm devices ought to report no less supported formats than before because naively, they map to hw:x,y where nothing changed. What is different?
I'll work on investigating how Windows handles this type of situation.
Great. I have doubts that Wine handles WAVE_FORMAT_DIRECT etc. correctly. But that's another story.