[alsa-devel] RFC: PCM extra attributes

[Takashi Iwai]

At Fri, 19 Jun 2009 12:58:21 +0100,
James Courtier-Dutton wrote:
> 
> 2009/6/19 Takashi Iwai <tiwai at suse.de>:
> > Hi,
> >
> > this is yet another topic I'm (currently) working on -- the addition
> > of PCM ioctls to get/set some extra attributes.  Basically, it adds
> > two simple ioctls for getting/setting extra attributes to the PCM
> > substream.  The attribute has a sort of TLV form,
> >
> 
> How is the association done between the pcm and the control?
> I would have thought an easy approach could be (from userland):
> snd_pcm_open( snd_pcm_t **handle, ...);
> snd_pcm_get_attr( handle, int attribute_id, *attributeX );
> snd_pcm_set_attr( handle, int attribute_id, *attributeX );

The ioctls aren't visible explicitly on alsa-lib.  What I initially
thought of is the function like:

  int snd_pcm_get_assoc_ctls(snd_pcm_t *, int num_ids, snd_ctl_id_t *ids);

> I.e Use the snd_pcm_t handle from the snd_pcm_open call to query and
> set any controls associated with the pcm. We could then remove those
> controls from being viewable in alsamixer and leave it to the
> application to control them.

The alsamixer view isn't the issue I'm concerned.
These spontaneous controls should be IFACE_PCM in the first place.
They shouldn't be IFACE_MIXER.  For example, IEC958 status bits can be
associated to a dedicated PCM substream.

One question is the visible volume control such as VIA DXS Volume.
But, I feel we should move them also to IFACE_PCM space and hide from
the alsamixer view.

> The only controls left in alsamixer would then be the global controls.
> E.g. Speaker arrangement, master gain control etc.

There will be still many strange controls that don't belong to
specific PCM substreams :)

> The result being that applications would never need to access the
> alsamixer controls, and instead only need to use the
> snd_pcm_get/set_attr interface on a per PCM basis that is much more in
> line with what applications actually need.
> 
> >An important note is that I'm planning to use this framework for
> >getting/setting the PCM (surround) channel mapping.
> Why would we want this channel mapping info in user space?

Because we don't know what channel to assign to which slot.
Whether the third channel is a center or a rear-left?

> Can't we just standardize on a single channel mapping as seen from
> user space, and get the driver to do any adaption if needed?

We assume the standard channel map, but unfortunately many hardwares
don't follow and are unable to remap.  Thus currently it's done in
alsa-lib route plugin.

However, there are devices (e.g. HD-audio) that require different
channel maps for different streams depending on chip.  Since the
alsa-lib config is static, it can't be changed well on the fly.
Thus, the driver needs first to provide some information about the
channel map so that alsa-lib (or PA) can handle the remapping
appropriately.

In addition, there are demands from apps to use different chanenl
maps.  FL/FR/C/LFE/RL/RR is far more standard except for ALSA.  We are
definitely minor.  So, sometimes it's good to adapt the majority's
choice...


thanks,

Takashi