[pulseaudio-discuss] Audio cards with subdevices

[Daniel Mack]

On Sat, May 02, 2009 at 04:34:24PM +0200, Lennart Poettering wrote:
> > > PA knows nothing about subdevices. What a subdevice is is highly
> > > dependant on the card and on the driver and there is no way to find
> > > out from userspace what they actually mean and are mapped to. We only
> > > access cards via "front:", "surround51:", "iec985:" and similar
> > > high-level access methods which hide those internals to us and map
> > > to right low-level channels.
> > 
> > Hmm, but it would be possible to iterate over all the subdevices and see
> > what kind of channels there are in each one, right?
> 
> No. To my knowledge ALSA has no API for that.

Hmm, then there is need to add one :) However, how does aplay do that
then?

> > The soundcard connected in this case exports a stereo pair in each
> > subdevice, and users can decided to use the second one by using ALSA's
> > '-D hw:0,0,1'. I carefully thought about how to export all channels of
> > the hardware in the driver when I wrote it, and the most logical view on
> > he hardware features is seeing them as group of stereo input and ouputs.
> > Things like "front:", "surround51:", "iec985:" are not appropriate, this
> > is just not what it does.
> 
> So these two subdevices are completely independant? I.e. can be
> independantly configured as if they were two seperate sound cards?
> From PA's perspective the most natural way to expose them to user
> space would be in two different cards then. But I guess from the
> drivers perspective that doesn't make much sense.

No, they're not entirely independant. They can not be configured to
different sampling rates, and all share the same clock. The driver
allows them to be opened and closed individually though.

(I could have exported them as 4 mono channels in one subdevice, but I
decided not to do that because they're presented as RCA stereo pairs on
the hardware and tools like aplay have a bigger problem dealing with
that.)

If I understand the ALSA docs correctly, there is three kinds of
information to qualify the sound path: the card, the device and the
subdevice, and on this card, the two streams are exposed as two
subdevices.

> How do they appear in "aplay -L"?

default:CARD=DJ
    Audio 4 DJ, Audio 4 DJ
    Default Audio Device

> I think the problem is simply that ALSA doesn't really cater for these
> setups. We cannot autodetect these cases. Device enumeration is
> (together with mixer handling) one of the weakest points in ALSA.

I don't know the ALSA API from that side, so I can't say from the top of
my head.

> > I would expect it to display all streams of all subdevices, so I can
> > address them individually, move a client from one to the next, select
> > one stereo pair of one particular subdevice as default, mute them and
> > set the volume seperately etc.
> 
> Hmm, so you have two sets of controls too?

Why not. At least for my case, there is vary rare cases where you would
chain two subdevices together and control them equally. But to keep
it more generic, an idea would be to allow exactly that and let the user
decide which devices belong together and should be handled with the same
set of controls. And in case PA _does_ know about that already (for
example because things are marked to be part of a 5.1 setup), there
could be a nice default.

> Unfortunately ALSA has no way to find the right mixer controls for a
> specific PCM playback channel. The only option we have is assuming that
> PCM and Master actually control the PCM volume. If you have multiple
> independant streams this wouldn't work, because we wouldn't know which
> slider maps to the second stream.

I can only speak for my case again, and I don't have hardware volumes.
The way PA currently handles that in software is fine for me.

> I am currently pondering to make the set of device strings and mixer
> paths PA probes for and uses configurable via config
> files. That would then allow easy extension which could be used by
> vendors to define weirder setups to probe for, and also allow proper
> i18n of mixer controls. I am not really sure though yet about this,
> because this honestly something that should be fixed on the ALSA
> level, and adding another mixer mapping layer on top of ctl, hctl,
> mixer, smixer smells really really foul.

Hmm, apart from the mixer things, the setup I'm dealing with is not
actually very weird. It's just about a number of stereo sound pairs
which are exported in an ALSA standard conform way. If it's just about
finding a way to iterate over them, that should be possible to add.

Daniel