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

[Andrew Eikum]

On Sat, Feb 11, 2012 at 06:24:08AM -0800, Chris Robinson wrote:
> On Saturday, February 11, 2012 2:05:18 PM Нискородов Серёжа wrote:
> > 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
> 
> You can use the "hw:" prefix for snd_ctl_open. All you need it for is to get 
> the card info and the available device indices, which doesn't rely on a custom 
> prefix.
> 
> Hmm, actually it seems winealsa already does this enumerating. Except it 
> hardcodes the plughw: prefix for the device string, uses the card index 
> instead of the name, and doesn't explicitly specify the parameter names (it 
> uses "x,y" instead of "CARD=x,DEV=y"). Perhaps I'll see about making some 
> patches.
> 

Please, I would love to see how someone more familiar with ALSA would
do this. My understanding is:

snd_ctl_name_hint() and friends:
+Includes user-specified, non-hw devices as well as true hw devices, but:
-Misses devices without 'hint' configs (Arch had this problem until a few weeks ago, other distros?)
-Duplicates devices many times
-Requires plughw: or other impossible-to-query prefix

snd_card_next() and friends:
+Each device listed is listed only once, but:
-Misses all user-specified, non-hw devices
-Requires plughw: or other impossible-to-query prefix

User-specified device list:
+Includes all devices a user wants, but:
-Really sucks from a UI perspective

Each option has huge downsides. I would have guessed that name_hint()
was the best choice, but you disagree with that, right?

> I'd agree with getting rid of alsa_try_open, unless there's a reason to keep 
> it. I don't think there's a good reason to prevent enumerating the extra 
> devices that can't be opened here though. It's status as unavailable/in-use 
> can be handled later, I think.
> 

The reason was to prevent displaying broken or useless devices.

Another way to do it would be to report these devices, but fail to
Initialize them with a more interesting error code (DEVICE_INVALIDATED
or something) and handle that correctly in dsound, winmm, and the
associated test suites (Jorg has a patchset that does most of this).
Unfortunately, we'd potentially be presenting broken devices to the
user, but I think it's probably better than trying to guess if a
device is broken like we do now.

Andrew