[gst-devel] multi-channel, try#2

[Ronald S. Bultje]

Hey gang,

so, I just thought we had this perfect layout thing... I made a
string-like approach, '3f2rlfe' being 5:1 sound, '2f2r' or '3f1r' being
4:0, you get the rest. Order of samples in buffers would be interleaved,
left-to-right, front-to-rear, then lfe. So, I thought I'd implement that
in faad and alsa.

I can't!

Faad is slightly more complicated. Faad actually has a position per
channel, not an enum, so the order of samples in the buffer can be
random. That means that I need to rearrange samples before pushing out
the buffer. Also, I can (in theory) not be very sure that the channel
locations are equally divided from left-to-right, which is assumed by
the above scheme, so 3-left-0-right channel setups won't work. That's
only a theoretical issue though, it'll never happen in practice.

Alsa has the same issue: I need to re-arrange buffers before using the
audio, because alsa expects LF,RF,LR,RR,C,LFE sample order. a52/dts spit
out C,LF,RF,LR,RR,LFE. Faad does it random. So this will not work, it'll
require all sort of conversions in plugins/elements, we don't want that.
Audioconvert should do it.

So, I do a new proposal: GstCaps carries a "channel_positions" property,
which is an array of strings of size gst_structure_get_int ("channels").
The strings indicate channel positions. Those could also be enums
(defined in gst/audio/audio.h), I don't really care. We'd have enums
like in faad.h, so left-front, right-front, center, left-side,
right-side, left-rear, right-rear, back, LFE. Think of it as your keypad
keys, you're the 5 and all numbers around you are possible channel
positions.

So, is everyone fine with this? I want to prevent using the "gradient"
approach from matroska, because it'll make conversions horribly
difficult, it's simply too complicated for now. I guess this is the most
workable solution. The magic will happen in audioconvert...

Ronald