Re: Audio Units - "fanout" and buses
Re: Audio Units - "fanout" and buses
- Subject: Re: Audio Units - "fanout" and buses
- From: Bill Stewart <email@hidden>
- Date: Fri, 26 Jul 2002 12:37:32 -0700
on 7/26/02 10:03 AM, Marc Poirier wrote:
>
from the AU docs:
>
>
The inOutputBusNumber parameter requests that audio be rendered for a
>
particular audio output of the AudioUnit. AudioUnitRenderSlice() must
>
be called separately to get rendered audio for each of its outputs.
>
The AudioUnit is expected to cache its rendered audio for each output
>
in the case that AudioUnitRenderSlice() is called more than once for
>
the same output (inOutputBusNumber is the same) at the same time
>
(inTimeStamp is the same). This solves the "fanout" problem.
>
>
What exactly is the "fanout" problem? I'm not familiar with this
>
expression at all. And what exactly is meant in this context when it
>
is said that the output should be "cached?"
With the additional work we've done with AU in Jaguar (and we're preparing a
summary of that which will be available when Jaguar is), we've decided to
veer away from solving the fan out issue this way because of the onerous
requirement that it places on every unit to maintain buffers of their
previous work (which also tends to also add additional complexity for
algorithms that can work in place)
I'll explain a couple of terms here:
We tend to use the words bus and elementID interchangeably when talking
about AudioUnits. If you think of a Mixer unit, you make input connections
to it by specifying an elementID of 0, 1, etc... And the Mixer will
typically have a single output element.
In the "real" world, you think of these as busses - a bus can have n
channels of data in it.
Fan out would occur when a source unit has two or more units that are
connected to the same output element:
SrcUnit
|
__________
| |
DestUnitA DestUnitB
(Both DUA and DUB would be getting their data from SrcUnit - output
element0)
For Jaguar we're now discouraging this kind of connection and would instead
see this situation dealt with through the insertion of a "fan-out" buffering
audio unit that would have a graph that looks like this:
SrcUnit
|
Fan_Out_Unit
| |
DestUnitA DestUnitB
Now - DUnitA would be getting data from element0 of the FOU and DestUnitB
gets "the same data" from element1 of the FOU
>
And while we're discussing this passage, it reminds me that I can't
>
figure out what the word "bus" is supposed to mean in
>
AudioUnit-speak. Is "bus" another way of saying "channel," as in a
>
stereo audio stream would have a left bus and a right bus, or bus 1
>
and bus 2? Or is it something else altogether?
Depends - if these two channels were being passed around on element0 say of
an audio unit, then they would be contained with a single bus... If the data
is coming through different connections on different elements, then they are
also on different busses.
Bill
--
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"...Been havin' some trouble lately in the sausage business," C.M.O.T.
Dibbler replied.
"What, having trouble making both ends meat?"
__________________________________________________________________________
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.