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

Chris Robinson chris.kcat at gmail.com
Mon Feb 13 11:26:46 CST 2012


On Monday, February 13, 2012 10:07:45 AM Andrew Eikum wrote:
> On Sat, Feb 11, 2012 at 06:24:08AM -0800, Chris Robinson wrote:
> > 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.

Not that I think I'm more familiar with ALSA, but what I do with OpenAL Soft 
is:

http://repo.or.cz/w/openal-soft.git/blob/e394d14cdab:/Alc/backends/alsa.c#l291

> 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?

Right. I think a combination of snd_card_next and a user-specified device list 
would be best.

> > 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.

But just because it can't be opened on enumeration doesn't mean it can't be 
opened later. I think the point of enumeration should be to get what cards 
exist, not what cards are usable (that comes later).

What does native Windows do if an app enumerates devices while a sepeate app 
has a device opened in exclusive mode? That's the kind of behavior I'd expect 
here.

> 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).

I suppose the actual error would be dependent on the error code from 
snd_pcm_open. A device that got removed since enumeration would be 
INVALIDATED, while a device that's simply busy would be IN_USE.



More information about the wine-devel mailing list