Re: Channels and frames
Re: Channels and frames
- Subject: Re: Channels and frames
- From: "B.J. Buchalter" <email@hidden>
- Date: Thu, 03 Nov 2005 23:10:13 -0500
on 11/3/05 8:29 PM, William Stewart at email@hidden wrote:
>
> On 03/11/2005, at 3:00 PM, B.J. Buchalter wrote:
>
>> Perhaps I have not looked at this closely enough, but I think I am
>> confused
>> in the same way that Michael is:
>
> To be honest, this isn't a matter of confusion. The problem is that
> you can't express what you want currently.; that is, you can't
> restrict capabilities once you start mixing different numbers of
> input and output channels.
So I think you are saying that if I want mono->mono with sidechain and
stereo->stereo with sidechain, that means I have to be able to deal with
other configurations as well. But I still am not quite clear on what
precisely I have to deal with.
>
>> Take the simple case of a plug in that has the following capabilities:
>>
>> Mono Input, Mono Sidechain Input, Mono Output
>> Stereo Input, Mono Sidechain Input, Stereo Output
>>
>> How does that get encoded as far as AU is concerned in terms of
>> elements and
>> kAudioUnitProperty_SupportedNumChannels?
>
> This has been discussed already in a previous email:
> { {1, 1} { 2, 2} }
Ok, but I am still confused; I must have a mental block. What does this
really mean in the case that there are two input elements and one output
element? What configurations are valid in this case?
Ok; I went back and reread what you already wrote -- please confirm the
following:
With 2 input elements and 1 output element and the SupportedNumChannels as {
{1, 1} { 2, 2} }
you can have
In 0: 1
In 1: 1
Out0: 1
In 0: 2
In 1: 2
Out0: 2
e.g. the configuration is per bus -- summed across busses? Is this correct?
Please help me out with my example listed above:
Mono Input, Mono Sidechain Input, Mono Output
Stereo Input, Mono Sidechain Input, Stereo Output
Is this representable or not?
>From what I understand, to do this I need to have two input busses and one
output bus. What I expect the possible configurations to be are:
Mono->Mono config:
ElementID 0 1
channels 1 1
ElementID 0
channels 1
Stereo->Stereo Config:
ElementID 0 1
channels 2 1
ElementID 0
channels 2
Is that what the kAudioUnitProperty_SupportedNumChannels you describe above
means? I did understand it to mean that. I guess that I am having problems
making the relationship between the SupportedNumChannels and the IO
elements. It seems to me that my example is
{2, 1}, {3, 2} with 2 input elements and 1 output element
But is there a way to specify that input element #1 is always a mono bus?
I guess my problem is that I'm not clear on what is representable (based
upon what you have said and the contents of 'IOChannelConfigurations.rtf').
If the scenario listed above is not representable, I kinda wonder why not. I
mean it seems odd to have a processor that has a mono input, a stereo output
and a stereo side-chain.
Anyway, just to be clear, I am not asking this as an academic question; I
would really like to understand it so that we can re-enable side-chain
support for the next release of our AU.
Bill, you said:
>The point of view we've taken with this really is to try to distinguish
>between the capabilities an AU has - and these are expressed without
>reservation or qualification. Now these might not work *that* well - but
But what I am saying is that if my AU has the capability of either 1->1 or
2->2 but both with a mono sidechain input, it doesn't seem like I can
actually express this capability; I can either overexpress or underexpress,
but I cannot describe the actual capabilities of the process. Again, this is
not academic -- these capabilities really reflect the capabilities of the
AU.
Do the kAudioUnitProperty_SupportedNumChannels configurations apply
independently to each bus (element) or is the sum of channels across all the
busses equal to the value in the kAudioUnitProperty_SupportedNumChannels
configuration -- and it is up to the host to partition them as it likes, and
I have to deal with it.
I'm sorry that I am finding this so confusing, but it really does seem like
it simply ignores a really simple and standard requirement; that is
partitioning the capabilities of the primary I/O from the sidechain I/O.
Am I just missing something?
>
>> Further, I think Michael's case is as follows:
>>
>> Mono Input, Mono Sidechain Input, Mono Output
>> Stereo Input, Stereo Sidechain Input, Stereo Output
>>
>> (ignoring Mono->Stereo or Stereo->Mono)
>
> No - that is not what he said BJ. The whole problem here is that he
> wants to do mono inputs and stereo output, but wants to explicitly
> dis-allow a mixture of mono and stereo inputs for a stereo output.
What he said was:
on 11/3/05 10:36 AM, john smith at email@hidden wrote:
> How can I inform the host about the channel count on the second bus?
>
> And how can I make sure that it only connect with 1 channel on the second
> bus when running in mono mode, and with 2 channels on the second bus when
> running in stereo mode?
> (i.e. avoid mono sidechains when running in stereo and vice versa).
Which to me means what I said above; again I am only arguing this because it
relates to what I am confused about in my own case.
Thanks for any clarification you can supply; I am really confused at this
point....
Best regards,
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