Hi,
Нискородов Серёжа wrote:
I really don't understand you. Why to write "plug:dmix" in wine, while you can configure ALSA devices natively via .asoundrc ?
plug:dmix is 9 characters, .asoundrc not well documented, with features that even people who've been writing them for long can learn any day, e.g. the influence of the "hint" field.
You're right that plug:dmix is not a good device, because it cannot capture.
Or are you write "plug:dmix" manually in all your applications, that use sound output?
No, Wine is the only one where I'm regularly testing dmix behavior instead of PulseAudio. All I want is the thing that "default" is in the absence of "pulse". That thing can do capture and playback.
The new "sysdefault" ALSA name is what I'd need, but it's too new for Ubuntu Intrepid or Lucid.
Because if tomorrow I will add a new device to .asoundrc, I will also have to add it to the WINE registry?
Registry or winecfg, is there such a difference?
What I observe is: The current device enumeration causes unusable devices, because some "meta devices" like "pulse" prevent accessing the underlying device hw:0 for 5 seconds. That is bug #28048.
Simple approach to avoid that: 1. Use only hw:* and "default" (or the registry override). 2. Try not to access "default" unless needed (perhaps last). 3. Try and gather information about the devices without "accessing" them. 4. Display information and let user choose one in winecfg. Winecfg should display the name of the current override, if any. A sort of "worse is better" approach.
Andrew Eikum's patch could be extended to parse a comma separated list of ALSA device names.
Elaborated approach: 1. Find a way to enumerate devices -- what way? Did you all agree on snd_ctl_name_hint? OpenAL uses snd_card_next 2. Try not to list identical devices multiple times -- how? 3. and 4. As above
I'm not opposed to the elaborate approach. I just don't want it to cause bugs and obscure behavior (like app A manages to open hw:0 because it tries it more than 5 seconds after "default", whereas app B fails because it tries immediately). My fear: the longer the list of devices, the more trouble there will be.
I should not fear that SW breaks. I want to be confident that it works.
Regards, Jörg Höhle