winealsa.drv patch to enum all software devices from .asoundrc

[Joerg-Cyril.Hoehle at t-systems.com]

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