Re: [LAD] Multi-Channel channel order

On Fri, 2009-08-14 at 22:54 +0200, Jörn Nettingsmeier wrote:
> David Robillard wrote:
> > Is there any existing 'standard' for the order of channels for
> > higher-than-stereo multi-channel streams?
> >
> > I'd assume this would be defined for interleaving or something, though
> > that's not what it's needed for: I think the port groups extension
> > should specify an order for all the channels of the various types of
> > group. Though this isn't necessary useful in the normal case (ports are
> > separate ala LADSPA), with this replication stuff and presumably other
> > things the host and plugin are going to have to deal with sets of
> > buffers, and having a predefined standard order for them seems like it
> > would make life a lot simpler and faster (and not having one seems to
> > have no benefit).
> >
> > For example, for discrete non-interleaved 5.1 (using a full channel for
> > the .1) we have 6 channels: left, center, right, rear left, rear right,
> > LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup)
> >
> > What order should these be passed in? Any existing practices?
>
> don't know about x.1, but for ambisonics, the emerging standard seems to
> be the "ambisonic channel number" scheme as defined here:
> http://ambisonics.ch/standards/channels/

Excellent, thanks!

> most favoured normalization scheme is sn3d, i.e. plugins will have to
> deal with inputs greater than 1.0f.

Hm. I never considered normalization... the reasoning and details
behind this seem to be pretty deep. I will maybe just say SN3D is the
normalization that should be used, and that's that?

This is similar to what we've done with LADSPA and LV2 and Jack anyway.
Audio is -1.0 .. 1.0 float, not clipped, period. Picking the/a best and
just saying that's what we use seems to have worked out very well vs the
the "support every little different encoding possible" method that
causes a huge complicated mess...

> of course, most applications up to now use the furse-malham standard of
> w xyz rstuv klmopq, each being normalized to 0..1, with the exception of
> W, which is additionally divided by sqrt(2).

That the letters aren't in any really sensible order in ACN does seem
pretty weird.

> but for political reasons, new plugins should use acn rather than fuma,
> so that's what should be defined as a standard first. if there is
> sufficient pressure and people are volunteering, another fuma scheme can
> always be added.

Sounds good to me.

(Fons, what is the situation WRT this stuff with your ambisonics
plugins? AFAIK they are the only ones that exist in LAD land)

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Aug 15 04:15:09 2009