[pulseaudio-discuss] Audio cards with subdevices

[Lennart Poettering]

On Sat, 02.05.09 22:43, Daniel Mack (daniel at caiaq.de) wrote:

> 
> 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?

It has no clue about subdevices and their meaning.

aplay -L only lists very very high-level devices that some driver
people found useful to have listed. But there is no "machine-readable"
explanation what they actually are good for. Also, it never worked for
me. On the 7 audio devices I currently have in my machine here it
lists exactly 1.5. And those entries are even wrong. So, yepp, big
disappointment.

aplay -l only lists very very low-level devices that some driver
people found useful to implement in their drivers. But there is no
"machine-readable" explanation what they actually are good for and how
the devices/subdevices actually map to outputs.

PA actually enumerates audio devices in a very ugly way these days
since the the ALSA enumeration APIs suck this much: we get the
availabilty of the cards from HAL/udev, and then autoprobe a few
high-level device strings (whose meaning we know) in all
combinations. That gives us a much more complete list of what is
actually supported by the driver/hw and how it interacts with each
other. But it is slow. And sucks big time.

> > 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.)

But internally you have four mono streams? Are you doing the
de-/interleaving in the kernel?

> > How do they appear in "aplay -L"?
> 
> default:CARD=DJ
>     Audio 4 DJ, Audio 4 DJ
>     Default Audio Device

Hmm, only as "default"? It would probably be good to include proper
name hinting support for your driver. Not that it would be too useful
given the state of the ALSA enumeration APIs, but better than nothing.

Right now alsa doesn't really expose to the apps at all that your two
subdevices can be used mostly independantly as you mentioned.

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

ALSA has a couple of device strings such as "surround51" which are
mapped in card-specific ways to the actual subdevices. That's how PA
is able to use surround sound cards properly.

For PA to be able to properly make use of this we'd need something
like "port1:xxx" and "port2:xxx" as standard devcie strings. But that
doesn't really make that much sense either.

Dunno. I geuss it's a simple fact that a sound card like yours cannot
really be supported in PA the way you want it right now and elegantly --
which is both ALSA's and PA's fault. It sucks.

On bright side, in the end it is always possible to configure PA
manually to use your low-level devices, by adding two lines like these
to default.pa:

  load-module module-alsa-sink device=hw:DJ,0,0
  load-module module-alsa-sink device=hw:DJ,0,1

It's just that the auto detection of this just doesn't fly right now. 

I'll keep this kind of hw in mind now though, to make sure that we can
support it eventually out-of-the-box and auto-detect on all
levels. For now that's as good as it get's. Sorry for that.

Lennart

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