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