[alsa-devel] The sense or non-sense of the device listing API (was: Status of ALSA "simple" mixer interface])

Lennart Poettering mznyfn at 0pointer.de
Sun Nov 25 20:56:15 CET 2007

On Wed, 21.11.07 16:23, Clemens Ladisch (cladisch at fastmail.net) wrote:

> Takashi Iwai wrote:
> > Lennart Poettering wrote:
> > > aplay -L suggest to use "surround71:" (and *only* that) as plugin for my
> > > usb webcam that only has a single mono channel.  What's going wrong?
> > > Any idea where I should be looking?
> > 
> > Since it's a USB device, maybe Clemens has a better clue...
> USB-Audio.conf defines all the surround devices because there are some
> devices that actually use them.  I could understand if "aplay -L" shows
> all the default device names _including_ surround71.
> I'm not sure how the device name list gets constructed; AFAICT the card-
> specific .conf files are not supposed to define hints.

Hmm, that would would be a serious limitation.

As it appears the device name lists *never* includes any suitable
device strings for mono-only devices, correct?

That too is a serious limitation, and makes the name listing API a bit worthless.

I am really not sure what to make of this device listing API, if it
lists mostly non-working devices, and doesn't list working devices.

Quite frankly, the whole device name API is not really useful as is
anyway, since it doesn't provide any hint to the code using it what
the properties are of the devices it lists. How should client code
ever know that "surround51" is the one to pick from the list when 5.1
sound is requested -- without having a static table of possible
devices and their properties somewhere in its own code? But if the
client codes has to define that table in its own code than the point
of the device naming API is mostly lost.

To work around the fact that the device naming API doesn't work as
documented, and also is not really that useful as an API anyway,
PulseAudio now probes all potentially available devices by opening
them, and having a large table listing the well known ALSA device
strings and their properties. Probing for possible devices like this
is ugly, and produces a lot of libasound debug output (which one
apparently can not disable without recompiling ALSA itself, or did I
miss something?).


Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

More information about the Alsa-devel mailing list