Re: AUGraphSetNodeInputCallback alternative on 10.4
Re: AUGraphSetNodeInputCallback alternative on 10.4
- Subject: Re: AUGraphSetNodeInputCallback alternative on 10.4
- From: William Stewart <email@hidden>
- Date: Thu, 14 May 2009 18:05:53 -0700
Yes...
There is a concern to be worried about here (and this explains why we
have the new API in 10.5)
AUGraph's 10.5 implementation uses the AU call below to add and remove
callbacks to the audio unit. The difference is the context on when you
do this while the graph is running. AUGraph has a message system that
is careful to apply edits to a running graph only on the render thread
either before rendering or after rendering.
If you try to connect 2 audio units, or add/remove a render callback,
from a thread that is not the render thread while the graph is
running, you can corrupt the AU state and cause crashes and other
nasty memory corruptions - basically, you can end up removing state
while that state is in use.
So, how to deal with this for 10.4
(1) If you *never* add or remove a callback to an audio unit that is
connected (and so would render) in a graph that is running, then you
don't need to do anything.
(2) If you need to add / remove a callback from an audio unit that is
connected (and so would render) in a graph that is running, you can do
one of two things:
(A) disconnect that audio unit from the graph, call AUGraphUpdate -
now the audio unit is not involved in the render chain, so you can
add / remove the callback. When you've done that, reconnect the audio
unit to the graph, call AUGraphUpdate - your callback will now get
called
(B) add / remove the render callback from an AUGraph's
RenderNotification callback (AUGraphAdd/RemoveRenderNotify). This is
actually harder to implement than (A) because you are executing your
edit on the render thread, so you have to have some way to message to
your callback code that you want to do this (and you have to be
careful about taking locks, etc)... However it maybe your only
alternative because doing (A) will mean that the audio unit you are
adding/removing the callback on will be disconnected from the graph
during the edit (which could cause a discontinuity in the audio)
(1) Is obviously the easiest :)
Hope that is clear
Bill
On May 14, 2009, at 2:57 PM, David Preece wrote:
Answering my own question...
Begin forwarded message:
The real sticking point is feeding the AU graph with data from my
code, previously achieved with a call to
AUGraphSetNodeInputCallback and callback. This is not implemented
on 10.4.
It's a property on the audio unit.
AURenderCallbackStruct cs={renderCallback,refCon};
AudioUnitSetProperty
(unit,kAudioUnitProperty_SetRenderCallback,kAudioUnitScope_Input,0,
&callbackStruct,sizeof(AURenderCallbackStruct));
works with a callback that looks like this:
OSStatus renderCallback(void *inRefCon,
AudioUnitRenderActionFlags *ioActionFlags,
const AudioTimeStamp *inTimeStamp,
UInt32 inBusNumber,
UInt32 inNumberFrames,
AudioBufferList *ioData) {}
_______________________________________________
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
_______________________________________________
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