Re: Opinions sought: AudioUnit Rendering
Re: Opinions sought: AudioUnit Rendering
- Subject: Re: Opinions sought: AudioUnit Rendering
- From: Bill Stewart <email@hidden>
- Date: Wed, 06 Mar 2002 11:27:07 -0800
on 5/3/02 7:45 PM, Laurent de Segur wrote:
>
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?
We are kind of kicking ourselves about not passing the render flags by
reference:)
This doesn't really solve the problem because its the case where the AU
calls RenderSlice on its inputs that is the real problem.
Laurent Cerveau made a pretty strong case to me about just using a NULL as
the return value for the AudioBuffer - which does kind of make sense - "Hey!
I've got nothing to give you" (though I think the dataSize or numChannels)
also pretty much says the same thing...
But then you raise an interesting point. We'd be tweaking the values of
these fields doing it that way, whereas a NULL is pretty explicit and maybe
not as tweaky
Bill
>
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.
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.