[gst-devel] channel configuration

[Ronald S. Bultje]

Hi,

we currently don't have any channel configuration things in GStreamer
yet. What I mean is simply: where are channels positioned in channels>2
streams? We probably want to add some information about this (only if
channels > 2 and setup != "simple stereo") to the GstCaps, at least in
the case of raw audio (audio/x-raw-{float,int}) because there it's not
embedded in the stream.

Reason I'm asking is because I'm currently wrapping libdts, and it faces
the same issue as liba52: I can only support stereo because any other
channel configuration can not be properly transmitted to the audio sinks
that support it (e.g. alsasink). Once we've defined audio channel
positioning, we can hopefully also extend audioconvert to convert from X
to Y channels. The faad and matroska plugin have similar problems, their
formats also support multi-channel sound, but the plugin doesn't really
handle it into detail or even correctly at all.

So, my proposal, I actually have two.

The first is to take the faad/a52/dts approach: use a number of front,
rear and low-frequency (LFE, ususally subwoofer) channels. You can then
get an audio configuration like 3F1R+LFE, which means 3 front (left,
center, right), 1 read (center) and one LFE. That means that in the case
of audio/x-raw-int,width=16,depth=16, the first two bytes in the buffer
are a sample for left-front, then the next two bytes are a center-front
sample, right-front, center-rear, lfe and then back to left-front again.
This is simple, managable, easily implementable but not very extendible.
The property would be called something like channel_positions and would
contain something like a GstStructure, which contains properties
'front', 'rear' and 'lfe', all ints, with their respective numbers. I
can shortcut this in gst-plugins/gst-libs/gst/audio/audio.[ch] if
wanted.

The second is to take the Matroska approach, where every channel has a
degree-number associated with it, which is the number of degrees (0-360)
from the center front speaker (point-of-origin). This is harder to
implement, especially because of the theoretical option that the
left-front-speaker in the audiosink is located slightly differently from
the intended left-front speaker position in the audio source. The buffer
has a similar layout as in the previous proposal, except that the order
of samples is as given in the array of channel positions instead of
simply left-to-right, front-to-rear-to-lfe.

Ideas? Is this ok for 0.8.x? Better proposals? Please shoot! I
personally think #1 is better for now (0.8.x). We might move over to the
second if that appears required for 0.10.x/later.

Ronald