Re: kAudioUnitProperty_SetRenderCallback disconnecting
Re: kAudioUnitProperty_SetRenderCallback disconnecting
- Subject: Re: kAudioUnitProperty_SetRenderCallback disconnecting
- From: William Stewart <email@hidden>
- Date: Thu, 16 Mar 2006 10:25:22 -0800
On 16/03/2006, at 8:41 AM, Geoff Hufford wrote:
On 3/2/06 12:56 PM, "William Stewart" <email@hidden> wrote:
We've been discussing this bug ourselves recently. The problem is
that adding/removing inputs are not thread safe and can lead to
sporadic crashes. AUGraph manages the connection side of this for
you, by adding and removing connections whilst the graph is running
in a particular manner - it does this on the render thread either
before or after the graph has rendered a slice. We don't have a
similar service for adding or removing render callbacks, so we will
be adding this as an API to graph in Leopard.
In the meantime, you will need to do some work - its not too hard.
Basically, you can attach a render notification to any of the AUs in
the render chain. Then you need to signal to this notification when
you want to add or remove a render callback.
I have consolidated all of my CAAudioFileReader connecting and
disconnecting
inside of the graph's main mixer render notify. If ioActionFlags &
kAudioUnitRenderAction_PreRender, I check if it is time for any of my
readers to begin, and then call AudioUnitSetProperty -
kAudioUnitProperty_SetRenderCallback. Then in
kAudioUnitRenderAction_PostRender I check if any readers have
completed and
I set the render callback to NULL.
This change that you recommended has worked very well at improving the
stability during playback.
Glad to hear this. We just posted an update to OpenAL that also does
a similar thing and that uses classes in our SDK to make sure these
operations are done in a thread safe manner. Those sources are
available at the OpenAL's source repository.
As you may recall from my list message thread "Streaming Graph to
file"
started 3/3/06. I am using the same graph to output to a file by
calling
AudioUnitRender(mixer) and writing with ExtAudioFileWrite. This
render and
write loop is running on the main thread. This approach is often
successful,
even with some complicated graphs that may be combining 50+
CAAudioFileReader instances that get connected/disconnected. After
each
render and write cycle is completed I do an allocate pass that may
make a
new CAAudioFileReader and Prime() it to be ready to Pull data. I
will also
delete any completed CAAudioFileReader instances.
Unfortunately this approach will crash intermittently, within
kAudioUnitProperty_SetRenderCallback, or occasionally within
ExtAudioFileOpen or ExtAudioFileDispose.
Is there any thread safeness issues that come up by calling
AudioUnitRender
directly?
No. The threading issues are due to an interaction between the I/O
thread when outputting to a device and the thread context you are on
when you make or break a connection or callback.
If you are doing all of these things on the same thread (ie. managing
the state of the graph as well as calling it's render) then there is
no thread issue.
Otherwise, I couldn't really say. You could have memory scribbling or
some other corruption. Have a look at the read me for AUValidation
(it is installed in the SDK Docs directory) - it explains how to use
the various malloc debug options.
Bill
Any other thoughts? Thanks.
Geoff
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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