As I mentioned, native mmdevapi doesn't do samplerate conversion or channel remixing. For shared mode, the device only opens with a pre-defined, user- selected rate and channel config. The only thing the default native mmdevapi will do is accept different sample depths/type (prefering float32). It's up to the app or whatever component is using mmdevapi to convert to the rate/channels given by GetMixFormat.
Any other conversion besides sample type is reliant on the user having installed plugins that'll do the wanted conversion. If it really becomes an issue (which it shouldn't), Wine could support these and have some by default.
I'm sorry, but I have no time to dive so deep and to study how mmdevapi works and how it have to work... So I cannot answer you.
My dmix51 device is defined in /etc/asound.conf. The difference is, it's defined to accept CARD, DEV, and SUBDEV parameters similar to regular dmix, so ALSA will enumerate it for each CARD and DEV that can support its output parameters.
Ok. I understand, I cannot ignore devices with colon in names.
Do you can play wav mono 11025Hz directly to your dmix51 device? Without "plug:" wrapper? With my soundcard I can't.
Nope, it won't open in a rate other than 48000hz without plug:. But again, that's fine for mmdevapi as it doesn't support rate conversion by default.
Hmm... Ok. But how it works in Windows? Does you mean that applications take care of sample rate conversion in Windows? Seems like it's not.
What I'd suggest is using snd_card_next, snd_ctl_open (which won't lock the device like snd_pcm_open), snd_ctl_pcm_next_device, and related, to enumerate available card names and device indices
Here is another trouble with snd_ctl_open. Not all devices in alsa configuration files have a predefined ctl. Especially defined by user, for example I don't always define a ctls for all my devices in .asoundconf So to use snd_ctl_open instead of snd_pcm_open I have to write some logic to fallback to hardware ctl if software device does not have own defined ctl. It's much more complicated, than I can do... At least for now.
, and have a configuration option in winecfg or somewhere to specify the prefix used ("dmix:", "plughw:", something custom, etc). Maybe another option to specify an additional list of custom devices that can't be detected this way, though most users shouldn't need that with the appropriate device prefix selected.
Just make sure to use the card name given by snd_ctl_card_info_get_id, so that the CARD parameter remains constant even if the card index changes.
I think you are greatly complicates this all. If all this devices can be enumerated and accessed by ALSA natively, then it all can be listed in WINE, why not? And user can select a device at his own risk. So what I suggest and what I can do for now: 1) To enumerate all devices, that ALSA can enumerate. First in list - default device (like it was before), after that - hardware devices (like it was before), and below all devices, that returns "aplay -L"; 2) To disable the testing of device avaliability (by alsa_try_open) while enumerating it. Thus, even devices that inaccessible at the time of enumeration can be added to the list. What you think about?