Re: Channels and frames
Re: Channels and frames
- Subject: Re: Channels and frames
- From: "B.J. Buchalter" <email@hidden>
- Date: Sat, 05 Nov 2005 00:49:59 -0500
on 11/4/05 10:32 PM, William Stewart at email@hidden wrote:
Thanks Bill!
> In thinking of how best to summarise this discussion (and answer some
> of the misconceptions, confusions, etc that were raised), I generally
> think this is best explained in the docs we already have prepared for
> this:
>
> /Developer/Examples/CoreAudio/Documentation/AudioUnits/
> IOChannelConfigurations.rtf
>
> Please read this document with some attention, as I doubt I can put
> this in better detail than has been explained there.
Definitely read it a couple of times...
I think the aspect that is confusing in that document is that it is really
talking about three different semantics, and it discusses them in an
intermixed way which obscures the semantic.
After reading your comments and the IOChannelConfigurations document a few
more times, I think I can summarize the semantics as:
If the channel info value (n) is
n > 0 specifies a concrete number of channels the host can specify for
each element
n = 0 no channels (and conversely no elements)
-3<n<0 any number of channels can be specified for the existing elements
(depending on the specific values of {n,m}, may imply linking of
input and output channel counts
n<=-3 fully dynamic configuration of the *elements*, subject to the
requirement that the total number of channels does not exceed -n
So, if the channel info is positive, it is specifying the available channel
counts for each of the available elements. I am not clear of whether or not
it is valid for AUs with only positive channel infos to have writeable
number of elements; I suppose from your description of the stereo mixer,
that this does in fact make sense; but I see no way to limit the number of
elements that the host configures, so it doesn't seem like this would make
sense in the context of a sidechain input, but only in the context of a
configurable number of homogeneous inputs.
If the channel info is negative, it is generally indicative of a fully
configurable AU. In the case the the channel info is a "large" negative
number, the AU is expressing a maximum number of channels available. So, in
this case, the channel info number is not globally referring to the channel
count per element -- it is referring to the total channel count of the AU.
So, given that the description keeps switching back between the different
semantics, it makes it difficult to understand that positive numbers are
applied globally per element, and negative numbers refer to the total AU
channel capability. In particular, the intermixing makes it seem like the
positive numbers may also refer to the total channel capabilities of the AU,
but in a different way than the negative numbers.
I think I understand this now, but I really don't think that the
IOChannelConfigurations document is particularly transparent; it's all in
there but it could really use a bit of reorganization to make the
distinctions more clear.
It would also be helpful, I think, if you guys added a couple of examples of
things that cannot be described properly by the channel info semantics,
(e.g. mono only side-chain on a stereo -> stereo AU), and what the closest
channel info will require of the plug-in.
> [informative examples snipped]
> Finally, if you wanted to just deal with mono or stereo, then the
> situation is much less complex, because you don't have an overlapping
> case. Thus:
> { {1, 1} {2, 2}}
> would result in 2 possible channel configurations for an AU
> (regardless of how many inputs or outputs it had):
> (A) In0:1 In1:1 Out0:1
> (C) In0:2 In2:1 Out0:2
This example I don't understand.
Why is does your case (C) have only one channel for In2 (which I think you
meant In1). Or was case (C) supposed be
(C) In0:2 In1:2 Out0:2
e.g. the 1:2 got flipped around in what you wrote?
That would make sense to me based on what you wrote before and the
IOChannelConfigurations.rtf.
Can you confirm this was a typo, or am I still not getting it?
That is less than ideal for the simple mono-sidechain case, but is
manageable.
> We've erred on the side of caution as we have found that trying to
> express constrained capabilities (such as all input buses must have
> the same number of channels, etc... ) are not easily generalised and
> quickly become overly complex. We believe the AU developer can
> achieve the affect they want (a flexible feature for the user) with
> some good UI or documentation that describes how different features
> of an AU are used to best advantage.
I guess that I missed the original debate (based upon what Urs wrote
yesterday), but while I understand the desire to not overcomplicate this
with things like linked constraints, I'm not sure why, for example the
channel constraints are not specifiable per bus. It seems like a *very*
desirable concept to not have to treat all the busses homogenously; for the
things like the mixer all the busses are homogeneous, but for things like
sidechains, the busses are generally not homogeneous. Anyway, it is the way
it is, and it is something that can be dealt with, but if the goal is for
the AU to be able to really advertise its capabilities and structure, it
seems like having the channel configuration stuff be global across all
busses really limits the ability of the AU writer to do so.
Best regards and TIA,
B.J. Buchalter
Metric Halo
5 Donovan Drive
Hopewell Junction, NY 12533 USA
tel +1 845 223-6112
fax +1 603 250-2451
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden