At Fri, 19 Jun 2009 12:58:21 +0100, James Courtier-Dutton wrote:
2009/6/19 Takashi Iwai tiwai@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