[alsa-devel] [RFC] Channel mapping API (take 2)

Takashi Iwai tiwai at suse.de
Wed Sep 5 08:59:42 CEST 2012


At Wed, 05 Sep 2012 08:49:29 +0200,
David Henningsson wrote:
> 
> On 09/04/2012 05:47 PM, Takashi Iwai wrote:
> > Hi,
> >
> > my proposal for channel mapping API seems accepted fairly well through
> > discussions at Plumbers, so I continued to work on it and uploaded the
> > updated version.
> >
> > The kernel part is found in sound-unstable tree topic/tlv-chmap branch
> >    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
> >
> > and the alsa-lib part is found in github tree topic/chmap branch
> >    git://git.github.com/tiwai/alsa-lib.git
> >
> > The updated parts are:
> >
> > - SNDRV_CHMAP_NA was newly added, indicating the channel is not
> >    available or silent.
> >
> > - The channel position value is masked in lower 16bit.
> >    The upper bits are used for more channel attributes as bit flags.
> >
> >    #define SNDRV_CHMAP_POSITION_MASK	0xffff
> >
> >    The phase inverted channel has this bit:
> >    #define SNDRV_CHMAP_PHASE_INVERSE	(0x01 << 16)
> >
> >    And the driver-specific non-standard channel position has this:
> >    #define SNDRV_CHMAP_DRIVER_SPEC	(0x02 << 16)
> 
> Just a comment here:
> 
> If this is meant to be used for those (mostly pro-audio) cards that just 
> have their outputs in simple numbers, maybe we should call it
> 
> #define SNDRV_CHMAP_NUMBERED
> 
> instead?

Well, "numbered" sounds something like sequential numbers, so I don't
think it's clearer.  The standard channel position is just a number,
too, after all.


> > - The alsa-lib API functions use snd_pcm_chmap_query_t and
> >    snd_pcm_chmap_t instead of ambiguous integer arrays.
> >
> > ================================================================
> > /** the channel map header */
> > typedef struct snd_pcm_chmap {
> > 	unsigned int channels;
> > 	unsigned int pos[0];
> > } snd_pcm_chmap_t;
> >
> > /** the header of array items returned from snd_pcm_query_chmaps() */
> > typedef struct snd_pcm_chmap_query {
> > 	enum snd_pcm_chmap_type type;
> > 	snd_pcm_chmap_t map;
> > } snd_pcm_chmap_query_t;
> >
> >
> > snd_pcm_chmap_query_t **snd_pcm_query_chmaps(snd_pcm_t *pcm);
> > void snd_pcm_free_chmaps(snd_pcm_chmap_query_t **maps);
> > snd_pcm_chmap_t *snd_pcm_get_chmap(snd_pcm_t *pcm);
> > int snd_pcm_set_chmap(snd_pcm_t *pcm, const snd_pcm_chmap_t *map);
> > ================================================================
> >
> > The rest aren't so much changed.  Only slight bug fixes.
> >
> > A big remaining question is whether the current kernel-side
> > implementation is OK.  We may add some PCM ops pointer instead of the
> > current style using the direct control tlv/read/write override.
> 
> That seems nicer, probably.
> 
> Also, if nothing is implemented on the kernel side for the specific 
> driver (e g we have many older drivers that I suspect no one will write 
> an implementation for),

Actually most of drivers with AC97 do support the channel mapping.
ISA drivers are still missing, but they support rarely multi channels,
thus no big merit by this API.

> what will alsa-lib return in that case?

Just an error, NULL.  I can change the function but passing triple
pointer (snd_pcm_chmap_query_t ***) would look really ugly.


Takashi


More information about the Alsa-devel mailing list