Hi,
I've never seen a documentation of what Wine expects from the ALSA/OSS/CoreAudio device.
- A bare bones "hw:0" device with all its restrictions, e.g. stereo 16bit only? As Wine provides no mixer, this would disallow playing multiple sounds concurrently (bug #NN) on most current sound cards. Some people seem to setup Wine via the registry to use that.
- "plug:hw" which can convert 8bit mono to 16bit stereo and provides resampling? (I forgot about the difference with "plughw")
- The "dmix" device, which only supports a single rate (typically 48000, see /usr/share/alsa/alsa.conf:defaults.pcm.dmix.rate), accepts only 32bit int(!) samples and restricts #channels like hw:0? This allows to open multiple devices.
- The "plug:dmix" device, which chains a resampler and converter with dmix so that it can accept any PCM format?
- "pulse", which like "plug:dmix" accepts any PCM format?
- "default", which presumably maps to either plug:dmix or pulse so as to accept any PCM format and open multiple devices?
It seems obvious Wine needs something as flexible as "pulse" or "plug:dmix" (pure "dmix" won't fit because Wine and apps don't cope well with the 32 bits samples requirement). Does mmdevapi change the equation, happy with dmix instead of plug:dmix as long as both rates are the same?
Given that, can't Wine delegate more to the OS? It seems quite stupid to e.g. write a resampler for Wine when ALSA and MacOS' Coreaudio already include one. (On MacOS, couldn't mmdevapi map more to MacOS' audio filter chains?)
What's the point of Winealsa's mmdevapi code iterating through ALSA's hw:N devices? IMHO only CoreAudio EXCLUSIVE mode can make use of them. It's a no-no for SHAREDMODE.
Or is the plan to be really happy with exclusive access to hw:0 (preventing non Wine apps from doing audio!?!) and implement in Wine's mmdevapi a true mixer as well as a high quality resampler for SHAREDMODE with RATEADJUST and WINMM needs?
Who can shed some light?
Regards, Jörg Höhle