winealsa.drv patch to enum all software devices from .asoundrc
Andrew Eikum
aeikum at codeweavers.com
Mon Feb 13 10:07:45 CST 2012
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
More information about the wine-devel
mailing list