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