[pulseaudio-discuss] [alsa-devel] Channel map API patches: to be 3.7 or not to be?

Takashi Iwai tiwai at suse.de
Wed Sep 12 09:03:25 PDT 2012


At Tue, 11 Sep 2012 14:24:09 +0200,
Takashi Iwai wrote:
> 
> At Tue, 11 Sep 2012 14:19:49 +0200,
> Clemens Ladisch wrote:
> > 
> > Takashi Iwai wrote:
> > > BTW, this reminds me of an open question:
> > >   is it useful to add SND_CHMAP_MONO, or is it just redundant?
> > >
> > > It's nothing but indicating a mono channel without any channel
> > > position, so I supposed SND_CHMAP_UNKNOWN being sufficient.  OTOH,
> > > SND_CHMAP_MONO would give a clear sign of mono streams while
> > > SND_CHMAP_UNKNOWN could be used for any other exceptional purposes.
> > 
> > What would it be used for?
> > 
> > Labeling surround channels is necessary for reordering them or for doing
> > up/downmixing.  A "mono" channel, however, does not appear to have any
> > semantic difference from a single "unknown" channel.
> 
> Right, that's the current status.  OTOH, labeling it as "mono" makes
> clear that it's an unaligned mono stream. i.e. it shows the purpose of 
> the stream by itself.

Looking at PulseAudio and gstreamer codes, they seem to have explicit
MONO channel definition.

typedef enum pa_channel_position {
    PA_CHANNEL_POSITION_INVALID = -1,
    PA_CHANNEL_POSITION_MONO = 0,
    ....

typedef enum {
  GST_AUDIO_CHANNEL_POSITION_INVALID = -1,

  /* Main front speakers. Mono and left/right are mututally exclusive! */
  GST_AUDIO_CHANNEL_POSITION_FRONT_MONO,
  ....

So, defining MONO seems rather standard.  Now I'm inclined to define
SND_CHMAP_MONO...


Takashi


More information about the pulseaudio-discuss mailing list