Re: Opinions sought: AudioUnit Rendering
Re: Opinions sought: AudioUnit Rendering
- Subject: Re: Opinions sought: AudioUnit Rendering
- From: Laurent de Segur <email@hidden>
- Date: Tue, 5 Mar 2002 19:45:26 -0800
How about adding a new audio unit selector
(kAudioUnitProperty_SetInputCallback2 or a better name) which would let
you register a callback proc with the AudioUnitRenderActionFlags being
passed as a pointer so you can now pass and get back states in it?
What I believe you will gain with this approach:
- It leaves room for expansion (it's a 32-bit value) because today you
need this specific state back, but maybe you'll need some other feedback
states tomorrow. What would you do using a special ptr value. Pass -1L
after having used NULL? Don't laugh, I've seen this.
- It would still be backward compatible and current clients or even
future ones would still use the current selector when they don't want
this new behavior (letting the client implement the current renderslice
signature passing the flags by value) Just think what would happen for
current clients receiving a null ptr if they don't expect it.
- you don't have to create special case for passing null pointers or
other creepy stuff, which has always been a way for getting the clients
of the API to trip into bizarre problems. Anyone here remembers
Mungle() on Mac OS? This routine had so many special cases that it was
just impossible to feel comfortable using it without picking in the
reference book each time.
Just an idea and definitely not the only way to solve this. It just
sounds cleaner than anything else I can think of.
Cheers,
LdS
On Tuesday, March 5, 2002, at 02:34 PM, Bill Stewart wrote:
We're currently tackling a problem of audio unit rendering that we'd
like
some opinions on.
The Problem:
Lets say that you have a graph of 3 DLS synths that all feed a dry input
into a reverb unit (via a mixer of course) that is then output to
hardware:
DLS1 DLS2 DLS3
| | |
| | |
M I X E R
|
|
R E V E R B
|
|
O U T P U T
So, the problem is this.
At some point the DLS units are not going to produce output. Currently
the
synth just passes back a buffer full of zereos. But the Reverb unit
still
has to process them.
The Reverb unit does the processing of course for the initial period
because
it has a reverb tail to render. And, even though this is infinitely
degenerating at some point (say -96dB) it can stop doing work if it
knows it
has received no valid input.
The flags that are passed in RenderSlice are only flags for the caller
to
pass its inputs, there's no pass by reference here so we can't use the
flags
field to signal this...
We could return a non-zero result code (but it isn't really an error -
it
just has no data to generate).
So, that leaves us I think with 3 alternatives...
(1) The Input provide an AudioBuffer pointer of NULL. That has the
potential
to crash audio units that are not prepared to get back from their
input a
NULL buffer.
(2) A buffer is provided back, but the mNumberChannels field is set to
zero.
- this has the potential problem of triggering some format change or
mis-understanding by the caller?
(2) A buffer is provided back, but the mDataByteSize is set to zero.
- presumably the caller is checking this and seeing a size of zero
would
indicate that there is no data to process?
We'd like there to be ONE way that an audio unit signifies this
situation,
and that all units become aware of this situation so they can at some
point
NOT do any work. The unit then would process as many samples as it
needs to
do its work for any "tail" it needs to deal with, and then at some
point it
will the return a similar "I've got no data to give you"...
Of course, on a global scale applications would still be expected to
start
and stop their processing as appropriate so I don't think that we will
percolate this down into the output units to the point that they would
actually stop their devices... (This would be too problematic because
the
processing might just be in a quiescent state and will wake up and start
feeding data again at some point in the future - but at least this
quiescent
state would then invoke a minimal CPU usage)
This can be a big win in graphs that are complex where there inputs are
ultimately of an irregular nature (ie. Sometimes there and sometimes
not).
Thanks
Bill
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"Thousands of years ago, cats were worshipped as gods. We have never
forgotten this."
__________________________________________________________________________
_______________________________________________
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.
_______________________________________________
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.