http://bugs.winehq.org/show_bug.cgi?id=27956
--- Comment #24 from Jörg Höhle hoehle@users.sourceforge.net 2011-09-22 04:30:24 CDT ---
I really do not want to have a mixer in Wine.
I never looked at mixer code. ;) I agree that Wine should delegate to the OS if it gets too complex (well, there's quite a balance to find, same with gfx).
Yes, "plughw:X" should do the trick. So far I didn't write that patch because I've not investigated how to have apps do a best effort at using the OS mixer's frequency. A typical scenario that I wish to avoid is: - PulseAudio runs at 44100 (cast in stone?) - winecfg is set to 48000 - DSound app thus uses 48000; downsampling in PA occurs; then perhaps upsampling because the HW only supports 48000!
Or invert the scenario: - dmix runs at 48000 (settable in /etc/alsa...) - winecfg set to 44100 - DSound app thus uses 44100 but might happily service 48000; wasteful upsampling occurs in dmix
Now throw in msacm: - ADPCM 8000 -> PCM 8000 is upsampled to 44100/48000 by PA/dmix; - ADPCM 8000 -> PCM 8000 might be accepted without resampling by hw:0 (depends on the HW); - At all cost, avoid ADPCM 8000 -> 44100 in Wine then resample to something else in plughw.
Of course, one could use plughw and set SND_PCM_NO_AUTO_RESAMPLE just to get channel and bitwidth conversion. BTW, I believe that these SND_PCM_NO_AUTO_* flags have no effect unless one of the plug devices is used.