Opinions sought: AudioUnit Rendering
Opinions sought: AudioUnit Rendering
- Subject: Opinions sought: AudioUnit Rendering
- From: Bill Stewart <email@hidden>
- Date: Tue, 05 Mar 2002 14:34:55 -0800
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.