14 Aug
2009
14 Aug
'09
2:36 p.m.
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?
Thanks,
-dr
14 Aug
14 Aug
3:30 p.m.
On Fri, Aug 14, 2009 at 12:36:36PM -0400, David Robillard wrote:
Is there any existing 'standard' for the order
of channels for
higher-than-stereo multi-channel streams?
...
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?
For 5.1 there are several orders in use. Same for AMB, in
particular higher order.
But: either it doesn't matter (e.g. for EQ), and where it does
matter a 'general' multichannel plugin (i.e. an essentially mono
one that knows about the multichannel port extension and can
replicate its internals) probably can't do the job anyway, and
you need a dedicated plugin.
That would be the case for e.g. an AMB compressor that would
apply the same gain to all channels, but derive it only from
one of them (W).
What is important is that a dedicated 5.1 plugin should be
compatible to a 'general' one that has 'anonymous' or just
numbered channels, and configured for 6 channels.
Also, e.g. an EQ that can be set to six channels should
work as well *any* 6-ch format. Which means that in that
case channel names are not a property of the plugin, but
of the host.
For a dedicated 5.1 or AMB plugin that would be different.
This suggest that there would some form of trying to match
a port defined by the host to that provided by the plugin.
If they are identical, all is OK, but that would not be
the only case, some other combinations have to work as well.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
3:52 p.m.
On Fri, 2009-08-14 at 19:29 +0200, Fons Adriaensen wrote:
On Fri, Aug 14, 2009 at 12:36:36PM -0400, David
Robillard wrote:
Oh well. I'll just come up with one that seems reasonable and has the
most overlap I guess, and maybe ship a header file with them all
#defined just for convenience's sake (this is all just for convenience,
see below)
Is there any existing 'standard' for the
order of channels for
higher-than-stereo multi-channel streams?
...
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?
For 5.1 there are several orders in use. Same for AMB, in
particular higher order. But: either it doesn't matter (e.g. for EQ), and
where it does
matter a 'general' multichannel plugin (i.e. an essentially mono
one that knows about the multichannel port extension and can
replicate its internals) probably can't do the job anyway, and
you need a dedicated plugin.
It doesn't matter in most cases (and all currently existing cases), but
there's easy things to come up with where it would be useful so it's
best to define. Useful data never hurts.
What is important is that a dedicated 5.1 plugin
should be
compatible to a 'general' one that has 'anonymous' or just
numbered channels, and configured for 6 channels.
Generally the idea with the groups extension is that all grouped ports
are labeled with their 'roles' (this is largely the point). They're
still compatible with plugins that don't have this data in the LADSPA
sense, you can hook it up manually or with messy heuristics etc. Note
all this port groups stuff is purely RDF data. Anything else that needs
to refer to multi-channel would naturally just use these definitions
though, so defining anything that would be useful (like channel order)
is wise, so e.g. things don't end up using a bunch of different
orderings.
Lack of this data just means the host is pretty much screwed when it
comes to doing nice higher level connecting of multi-channel streams.
It's not really feasible to do so, except:
Also, e.g. an EQ that can be set to six channels
should
work as well *any* 6-ch format. Which means that in that
case channel names are not a property of the plugin, but
of the host.
Good point. I guess nothing really needs to be done here though, the
plugin can just label a bunch of ports as part of a group without a
role.
For a dedicated 5.1 or AMB plugin that would be
different.
This suggest that there would some form of trying to match
a port defined by the host to that provided by the plugin.
If they are identical, all is OK, but that would not be
the only case, some other combinations have to work as well.
I generally think of this problem in terms of "plugin telling the host
precisely what it's I/O is". Hosts can be as clever as they like :)
Ideally (IMO), hosts would look at all the plugins they have to find
converters. For example, if you have stereo, and need to convert it
into 5.1, check all your plugins for something with a stereo in
corresponding to a 5.1 out. Hardcoded logic in hosts for this kind of
thing is unfortunate, especially for e.g. ambisonics where it's far from
trivial behaviour.
Thanks,
-dr
6:32 p.m.
On Fri, Aug 14, 2009 at 01:52:38PM -0400, David Robillard wrote:
I generally think of this problem in terms of
"plugin telling the host
precisely what it's I/O is". Hosts can be as clever as they like :)
Or a plugin telling a host what its I/O *can* be - i.e. offering
several options and letting the host or user decide which one
makes sense. For example a plugin could offer to do the right thing
for either general multichannel (all equal) or for some AMB format.
Then it depends on the host or user to select the right mode. It's
this sort of thing I had in mind when writing that maybe you can't
just rely on port properties alone.
Ideally (IMO), hosts would look at all the plugins
they have to find
converters. For example, if you have stereo, and need to convert it
into 5.1, check all your plugins for something with a stereo in
corresponding to a 5.1 out. Hardcoded logic in hosts for this kind of
thing is unfortunate, especially for e.g. ambisonics where it's far from
trivial behaviour.
True... But take into account that such conversions would be the
exception rather than the rule. You could have a 5.1 mixdown session
that at the end is converted to stereo for a CD release, but you would
normally never have anything that converts between different formats
more than once. So it's perfectly acceptable to require a user decision
in case such a conversion is needed. But I do agree 100% that there
should be no hardcoded logic for such things - it would get it wrong
most of the time, no matter how hard you try.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
6:54 p.m.
On Fri, 2009-08-14 at 22:31 +0200, Fons Adriaensen wrote:
Sure. Just a host/UI issue. Even using plugins to do it you'd probably
have to defer to the user to ask which one to use anyway.
-dr
On Fri, Aug 14, 2009 at 01:52:38PM -0400, David
Robillard wrote:
You can pretty much literally describe anything with port properties (or
similar), since RDF is a fully powerful data model. Something like this
will involve some binary things as well, yes. As usual that is kept to
a minimum because data is more flexible.
I agree both things you mention here (listing the specific formats a
group can support, or 'general multi-channel) are needed. This isn't
too bad, it could e.g. support 5.1 or WXY or whatever, or any number of
channels from 1 through 16.
The only thing I can think of that would make it hairier is if, say, the
plugin could only support multiples of some number of channels. Is this
necessary where the upper limit is infinity? Are there any more complex
requirements that are reasonable? I can't think of any, this seems way
beyond reasonable to me.
I generally think of this problem in terms of
"plugin telling the host
precisely what it's I/O is". Hosts can be as clever as they like :)
Or a plugin telling a host what its I/O *can* be - i.e. offering
several options and letting the host or user decide which one
makes sense. For example a plugin could offer to do the right thing
for either general multichannel (all equal) or for some AMB format.
Then it depends on the host or user to select the right mode. It's
this sort of thing I had in mind when writing that maybe you can't
just rely on port properties alone. Ideally (IMO),
hosts would look at all the plugins they have to find
converters. For example, if you have stereo, and need to convert it
into 5.1, check all your plugins for something with a stereo in
corresponding to a 5.1 out. Hardcoded logic in hosts for this kind of
thing is unfortunate, especially for e.g. ambisonics where it's far from
trivial behaviour.
True... But take into account that such conversions would be the
exception rather than the rule. You could have a 5.1 mixdown session
that at the end is converted to stereo for a CD release, but you would
normally never have anything that converts between different formats
more than once. So it's perfectly acceptable to require a user decision
in case such a conversion is needed. But I do agree 100% that there
should be no hardcoded logic for such things - it would get it wrong
most of the time, no matter how hard you try.
7:15 p.m.
On Fri, Aug 14, 2009 at 04:54:57PM -0400, David Robillard wrote:
The only thing I can think of that would make it
hairier is if, say, the
plugin could only support multiples of some number of channels. Is this
necessary where the upper limit is infinity? Are there any more complex
requirements that are reasonable? I can't think of any, this seems way
beyond reasonable to me.
I don't see ATM any reason to put restrictions on N (apart from some
reasonable maximum). One thing I can imagine is that the internal
processing would be in groups of 4 channels to exploit SSE. But even
in that case the interface could be 1,2, or 3 less.
On the other hand, this makes a case for using an interleaved format,
and for rounding up the number of _physical_ channels if the number
of _logical_ channels is not a multiple of four. In other words the
host would just provide some dummy channels allowing the plugin to
use groups of four without having to copy on input an output.
Just a silly idea, but I'm considering exactly that for the internal
organisation of an app I'm working on. But then there are also the
graphical CPUs today, again changing the picture.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
7:51 p.m.
On Fri, 2009-08-14 at 23:14 +0200, Fons Adriaensen wrote:
On Fri, Aug 14, 2009 at 04:54:57PM -0400, David
Robillard wrote:
Sounds reasonable. I think it should be straightforward to model it in
such a way that new kinds of advanced restrictions can be added later if
it's necessary anyway, so if there's no need for this kind of stuff now,
no sense trying to define it.
The only thing I can think of that would make it
hairier is if, say, the
plugin could only support multiples of some number of channels. Is this
necessary where the upper limit is infinity? Are there any more complex
requirements that are reasonable? I can't think of any, this seems way
beyond reasonable to me.
I don't see ATM any reason to put restrictions on N (apart from some
reasonable maximum). One thing I can imagine is that the internal
processing would be in groups of 4 channels to exploit SSE. But even
in that case the interface could be 1,2, or 3 less. On the other hand, this makes a case for using an
interleaved format,
and for rounding up the number of _physical_ channels if the number
of _logical_ channels is not a multiple of four. In other words the
host would just provide some dummy channels allowing the plugin to
use groups of four without having to copy on input an output.
Hm. True. Well, if it works out that this stuff can be spec'd such
that more complex restrictions like this can be added, we can ignore
this for now. So, we'll see. Tempting case though, if the plugin did
know there's multiple of 4 buffers always, it could use a literal 4 in
the loop, and recent GCC would probably successfully vectorize it...
I guess interleaving coming up eventually was inevitable :/
One major disadvantage to using interleaving anywhere in the plugin
interface is that it makes redistributing the data to/from LADSPA (and
LADSPA style LV2) plugins significantly more expensive, difficult, and
impossible to do in place. Ditto for JACK buffers.
Given that, I think avoiding interleaving at the plugin API level is
probably very desirable unless there's a really compelling reason to do
otherwise.
(GStreamer uses interleaved internally, if that's worth anything)
-dr
3:34 p.m.
David,
What order should these be passed in? Any existing
practices?
If you use some sort of syntactic port naming, like [foo.L, foo.R,
foo.RL, foo.RR, foo.C, foo.LFE] the order doesn't matter - the
application that does the connection should be aware of this, of course.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
3:53 p.m.
On Fri, 2009-08-14 at 19:34 +0200, Florian Faber wrote:
David,
Yes, this information is not necessary in the usual context of port
groups. In particular, the port index order isn't related.
Just useful data that will be needed for other things.
Cheers,
-dr
What order should these be passed in? Any
existing practices?
If you use some sort of syntactic port naming, like [foo.L, foo.R,
foo.RL, foo.RR, foo.C, foo.LFE] the order doesn't matter - the
application that does the connection should be aware of this, of course. 
6:54 p.m.
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/
most favoured normalization scheme is sn3d, i.e. plugins will have to
deal with inputs greater than 1.0f.
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).
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.
regards,
jörn
7:44 p.m.
On Fri, 2009-08-14 at 22:54 +0200, Jörn Nettingsmeier wrote:
David Robillard wrote:
Excellent, thanks!
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/ 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
8:38 p.m.
David Robillard wrote:
fine. it's just that plugins *will* have to deal with signals greater
than 1.0 in some channels, because that's how BOB wants them to be.
the weird thing is the order of the WXYZ... scheme. when you look at the
spherical harmonics components, WXYZ... is a pile of historic junk that
is totally unintuitive. consider for instance the components which are
invariant under z axis rotation:
W: first (and only) of the 0th order components
Z: last of the 1st order components
R: first of the 2nd order components.
so it's time to do away with backward compatibility in this case and
create a better world for our grandchildren, even if our generation has
to suffer in this world.
there is also the CMT toolset by richard furse.
both furse and malham have expressed no regrets at doing away with FuMa
at this year's ambisonics symposium...
i know fons hates fuma and has publicly stated he wants to get rid of
it, even though the current AMB set still uses it for historical
reasons. there will probably be adaptor plugins for a transitional
period - i recently used a quick hack to interface FuMa plugins with the
graz cube, who can only deal with ACN and their own in-house scheme
(which is being phased out in favour of ACN).
best,
jörn
On Fri, 2009-08-14 at 22:54 +0200, Jörn Nettingsmeier
wrote:
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
extra emphasis on "not clipped", no mention of -1.0 .. 1.0 :-D
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)
9:20 p.m.
On Sat, 2009-08-15 at 00:38 +0200, Jörn Nettingsmeier wrote:
the weird thing is the order of the WXYZ... scheme. when you look at the
spherical harmonics components, WXYZ... is a pile of historic junk that
is totally unintuitive. consider for instance the components which are
invariant under z axis rotation:
W: first (and only) of the 0th order components
Z: last of the 1st order components
R: first of the 2nd order components.
so it's time to do away with backward compatibility in this case and
create a better world for our grandchildren, even if our generation has
to suffer in this world.
Should have changed the letters too in the process? :)
I agree historic junk should be cast away in general, and /definitely/
in this case. Shiny new specs = opportunity to fix past mistakes...
there is also the CMT toolset by richard furse.
both furse and malham have expressed no regrets at doing away with FuMa
at this year's ambisonics symposium...
If ever there was a plugin collection that needs some love, that's the
one; the nemesis of valgrind loving LADers everywhere :)
David Robillard wrote:
fine. it's just that plugins *will* have to deal with signals greater
than 1.0 in some channels, because that's how BOB wants them to be.
I just meant this is what normal audio is in LADSPA/etc, i.e.
historically we've just picked one and said that's it, and it's worked
fine, so there's little reason to try and accomodate a bunch of
different ways to encode ambisonic streams and make everyone have to
deal with that nuisance.
On Fri, 2009-08-14 at 22:54 +0200, Jörn
Nettingsmeier wrote:
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
extra emphasis on "not clipped", no mention of -1.0 .. 1.0 :-D 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) i know fons hates fuma and has publicly stated he
wants to get rid of
it, even though the current AMB set still uses it for historical
reasons. there will probably be adaptor plugins for a transitional
period - i recently used a quick hack to interface FuMa plugins with the
graz cube, who can only deal with ACN and their own in-house scheme
(which is being phased out in favour of ACN).
Hm. Unfortunate. No straight port then :/
Though if there's two (open) plugin collections that do ambisonics, and
the authors of both hate fuma, the LADSPA stuff can just move to ACN
along with ports anyway.
What is the result if you connect a fuma stream to a ACN stream, getting
the channels matched correctly but just not the normalisation? Is it
just clipping, or is the interpretation completely different?
-dr
9:04 p.m.
On Fri, Aug 14, 2009 at 05:44:21PM -0400, David Robillard wrote:
Again I would 100% support that, but it is not current practice.
Any application that uses this scheme will be the brave one that
starts a revolution.
Excellent, thanks!
That is also the one I'd support, together with either n3d or n3d
normalisation, but I wish I could share Joern's optimism about it
being accepted...
The matter came up in last year's AMB meeting in Graz. That was
followed by some very hot and mostly useless discussion on the
surround sound list and at various other shady ad-hoc places.
It was scheduled to be discussed again at this year's meeting
in Graz where both Joern and I were present along with the
complete beau monde of Ambisonics, But no conclusion was arrived
at, first because we didn't have enouth time and second because for
many of the participants it was something they were not prepared
for - the necessary introductory talk took almost all the time
we had.
> most favoured normalization scheme is sn3d, i.e.
plugins will have to
> deal with inputs greater than 1.0f.
Not really - for n3d some of the _panning gains_ can be > 1 iff you
set W = 1. Absolute levels are not the same thing as relative gains.
For sn3d the panning gains are <= 1.
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)
The plugin set (did you get the latest and greatest ?) uses FuMa
and also it assumes that positive azimuth is to the right which is
plain wrong. The only reason for that is that most hosts can't
create a widget that has negative values to the right and positive
ones to the left (and LADSPA can't tell them they should do it).
The plugins will remain what they are, but my support for FuMa ends
there. All new stuff will be n3d or sn3d and use either the 'computer
graphics' (= ACN) or 'Gerzon' order. If the new stuff is more than a
plugin it could *maybe* offer FuMA as an option at the external
interfaces, as e.g. AmbDec does. Internally everything will be n3d.
Anyway, if ports are labeled in 'machine readable' way the order
doesn't matter - a host will be able to sort things out. It does
matter e.g. in a file format that doesn't have metadata to describe
the order.
Dave, don't worry about the weird order of the single character
names shown on the web page about ACN, They are mentioned only
to show how the order relates to the FuMa one. ACN doesn't use
these names, it only uses the numbers.
Another outcome of the Graz meetings is that the port groups
that are currently named H#V# should really be named H#P#.
The H#V# ones do also exist, but are different. I'll have to
rename all existing AmbDec presets for the same reason.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
9:58 p.m.
On Sat, 2009-08-15 at 01:04 +0200, Fons Adriaensen wrote:
Again I would 100% support that, but it is not current practice.
Any application that uses this scheme will be the brave one that
starts a revolution.
As far as LV2 goes, there's basically zero precedent whatsoever, so
brave new world it is.
Whichever is most reasonable if you could start anew and pick a single
standard is the one to choose. If other stuff all bogged down with
legacy is different, whatever. Not everything uses -1..1 float audio
either. Conversion isn't the end of the world. Even if the real world
has a billion different formats, we can at least make this world nicer.
It's the Jack way :)
I was just thinking a direct port to LV2 would be nice, but whatever.
Sounds like a level of abstraction is/will be in there somewhere that
can deal with it anyway.
(You could use the same ontology for lrdf on LADSPA plugins, but the
chances of that actually being used are probably slim. I am not
personally interested in it, anyway, but the ontology is deliberately
simple and 'flat' to make it possible to use in basic things)
On Fri, Aug 14, 2009 at 05:44:21PM -0400, David
Robillard wrote:
I'm glad this stuff is actually defined elsewhere. :)
Jörn Nettingsmeier wrote:
> most favoured normalization scheme is sn3d, i.e. plugins will have to
> deal with inputs greater than 1.0f.
Not really - for n3d some of the _panning gains_ can be > 1 iff you
set W = 1. Absolute levels are not the same thing as relative gains.
For sn3d the panning gains are <= 1. 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)
The plugin set (did you get the latest and greatest ?) uses FuMa
and also it assumes that positive azimuth is to the right which is
plain wrong. The only reason for that is that most hosts can't
create a widget that has negative values to the right and positive
ones to the left (and LADSPA can't tell them they should do it).
The plugins will remain what they are, but my support for FuMa ends
there. All new stuff will be n3d or sn3d and use either the 'computer
graphics' (= ACN) or 'Gerzon' order. If the new stuff is more than a
plugin it could *maybe* offer FuMA as an option at the external
interfaces, as e.g. AmbDec does. Internally everything will be n3d. Anyway, if ports are labeled in 'machine
readable' way the order
doesn't matter - a host will be able to sort things out. It does
matter e.g. in a file format that doesn't have metadata to describe
the order.
For normal plugins that just use the metadata, it's all based on the
semantic "role" and order is irrelevant.
Dynamic stuff probably needs the order though. Plugin code doesn't want
to have to deal with this crap when the spec can easily make the host
have to pass it in a certain order (when there's a choice, complexity
goes in the host).
Dave, don't worry about the weird order of the
single character
names shown on the web page about ACN, They are mentioned only
to show how the order relates to the FuMa one. ACN doesn't use
these names, it only uses the numbers.
Hrm. I wonder if the names should be changed then... currently they are
wChannel, xChannel, etc.
I'll have to think about how to work both in there without it being a
PITA to query.
Another outcome of the Graz meetings is that the port
groups
that are currently named H#V# should really be named H#P#.
The H#V# ones do also exist, but are different. I'll have to
rename all existing AmbDec presets for the same reason.
OK, thanks
-dr
15 Aug
15 Aug
10:03 p.m.
On Sat, 2009-08-15 at 01:04 +0200, Fons Adriaensen wrote:
On Fri, Aug 14, 2009 at 05:44:21PM -0400, David
Robillard wrote:
Another outcome of the Graz meetings is that the port groups
that are currently named H#V# should really be named H#P#.
The H#V# ones do also exist, but are different. I'll have to
rename all existing AmbDec presets for the same reason.
Do you have a link or anything about this? (What does the P stand for
etc)
Thanks,
-dr
16 Aug
16 Aug
9:26 a.m.
David Robillard wrote:
On Sat, 2009-08-15 at 01:04 +0200, Fons Adriaensen
wrote:
the old approach to mixed order was to have a horizontal-only
higher-order set and a first-order full periphonic set.
that means if a source is on the horizontal plane, you benefit from the
higher angular resolution of higher-order, but as soon as it moves up or
down, you are back to first-order. bad.
the new scheme as proposed by travis makes sure that you have full
higher-order azimuthal resolution at all elevations, but only
first-order elevational resolution. the only downside is that it uses
more channels.
the paper is here:
http://ambisonics.iem.at/symposium2009/proceedings/ambisym09-travis-newmixe…
now that the important difference between those two approaches has been
pointed out, it seems that the old shorthand notation needs to be changed.
we used to write *3h1v*, which was supposed to mean 3rd-order
horizontal, first-order vertical. but outside the horizontal plane,
there is no 3rd order at all. so the correct new shorthand is *3h1p*, to
be read "*3*rd-order *h*orizontal components, superimposed with a
*1*st-order *p*eriphonic set".
the improved scheme by travis will now be denoted as *3h1v*, which can
be read as "*3*rd-order *h*orizontal resolution at all elevation levels,
combined with *1*st-order *v*ertical resolution at all azimuths"...
On Fri, Aug 14, 2009 at 05:44:21PM -0400, David
Robillard wrote:
Another outcome of the Graz meetings is that the port groups
that are currently named H#V# should really be named H#P#.
The H#V# ones do also exist, but are different. I'll have to
rename all existing AmbDec presets for the same reason.
Do you have a link or anything about this? (What does the P stand for
etc) 
17 Aug
17 Aug
3:25 p.m.
On Friday 14 August 2009 17:44:21 David Robillard wrote:
(Fons, what is the situation WRT this stuff with your
ambisonics
plugins? AFAIK they are the only ones that exist in LAD land)
SuperCollider also has a bunch of UGens doing ambisonics.
Order used is: W,X,Y,Z, R, S, T, U, V.
sincerely,
Marije
16 Aug
16 Aug
1:35 p.m.
On Fri, 14.08.09 12:36, David Robillard (dave(a)drobilla.net) wrote:
Is there any existing 'standard' for the order
of channels for
higher-than-stereo multi-channel streams?
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?
Microsoft WAVEX and Apple CAF encode the channel mappings in a bitmap
that doesn't limit you much in which channels you pick, but it does
imply a specific order:
http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/CAF_s…
http://www.microsoft.com/whdc/device/audio/multichaud.mspx#EKLAC
Look for kCAFChannelBit_xxx resp. SPEAKER_xxx.
The CAF wand WAVEX channel mask is identical, however they used
different names for the same channels. (CAF allows more flexible
definitions via a different chunk, too though, which enables
ambisonics). Given that both MS and Apple seem to follow this rule it
might be a good idea to follow it too.
And finally, RFC3551/AIFF-C (see section 4.1 of the RFC) defines an
implicit channel mapping based on the number of channels. In some
cases it might make sense to follow that rule.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
2:56 p.m.
On Sun, Aug 16, 2009 at 05:34:47PM +0200, Lennart Poettering wrote:
Look for kCAFChannelBit_xxx resp. SPEAKER_xxx.
The CAF wand WAVEX channel mask is identical, however they used
different names for the same channels. (CAF allows more flexible
definitions via a different chunk, too though, which enables
ambisonics). Given that both MS and Apple seem to follow this rule it
might be a good idea to follow it too.
That would be L R C Lfe Ls Rs.
Protools uses L C R Ls Rs Lfe, which is the 'Dolby'
order as used in the film industry and also for AC3
encoding.
DTS and AAC use C, L, R, Ls, Rs, Lfe.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
3:14 p.m.
On Sun, 2009-08-16 at 18:55 +0200, Fons Adriaensen wrote:
On Sun, Aug 16, 2009 at 05:34:47PM +0200, Lennart
Poettering wrote:
What a mess. In a maze of little standard, all different, I think I
will use the simple rule: "left-to-right, then front-to-back, finally
LFE", which seems to match the dolby/AC3/Protools order.
e.g. (LFE in parenthesis)
5.1:
1 2 3
4 5
(6)
7.1:
1 2 3
4 5
6 7
(8)
7.1 wide:
1 2 3 4 5
6 7
(8)
etc. Least it's logical. :) A downside is that just taking the first
two channels doesn't get you stereo, which could suck if you have a 5.1
"multi-buffer" output and a stereo "multi-buffer" input and the
buffers
are just layed out one after another, because if it was LRC you could
connect them directly...
OTOH it's impossible to define a scheme where this is doable for all
combinations, and a proper converter plugin should probably be used in
this case to avoid losing sound anyway.
-dr
P.S. "multi-buffer" is just hypothetical
Look for kCAFChannelBit_xxx resp. SPEAKER_xxx.
The CAF wand WAVEX channel mask is identical, however they used
different names for the same channels. (CAF allows more flexible
definitions via a different chunk, too though, which enables
ambisonics). Given that both MS and Apple seem to follow this rule it
might be a good idea to follow it too.
That would be L R C Lfe Ls Rs.
Protools uses L C R Ls Rs Lfe, which is the 'Dolby'
order as used in the film industry and also for AC3
encoding.
DTS and AAC use C, L, R, Ls, Rs, Lfe.
3:45 p.m.
On Sun, Aug 16, 2009 at 01:14:53PM -0400, David Robillard wrote:
What a mess. In a maze of little standard, all
different, I think I
will use the simple rule: "left-to-right, then front-to-back, finally
LFE", which seems to match the dolby/AC3/Protools order.
e.g. (LFE in parenthesis)
5.1:
1 2 3
4 5
(6)
7.1:
1 2 3
4 5
6 7
(8)
7.1 wide:
1 2 3 4 5
6 7
(8)
Makes perfect sense to me. Having Lfe last is also
convenient as it isn't (shouldn't be) used for music.
etc. Least it's logical. :) A downside is that
just taking the first
two channels doesn't get you stereo,
You shouldn't count on getting usable stereo from
just L,R anyway.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
3:16 p.m.
On Sun, 2009-08-16 at 17:34 +0200, Lennart Poettering wrote:
And finally, RFC3551/AIFF-C (see section 4.1 of the
RFC) defines an
implicit channel mapping based on the number of channels. In some
cases it might make sense to follow that rule.
RFC made my ears perk up, but unfortunately this is pretty limited, and
number of channels doesn't uniquely identify scheme very well anyway.
Cheers,
-dr
5373
days inactive
5376
days old
linux-audio-dev@lists.linuxaudio.org
22 comments
6 participants
participants (6)
-
David Robillard -
Florian Faber -
Fons Adriaensen -
Jörn Nettingsmeier -
Lennart Poettering -
nescivi