[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