On 09.12.2016 at 20:21 Doug Wyatt wrote:
> In the case of anything else built on AUBase, including
> AUMultiChannelMixer, it's not a matter of the property being changed
> asynchronously and waiting for a notification (I'm reinstalling
> Xcode at the moment, hard to look at code, but from memory, setting
> the render callback might not send a notification anyhow).
> The usual problem is that one can be in the middle of rendering
> upstream of the AU while trying to disconnect, and it's not the AU's
> responsibility to protect against that.
> One solution is to use a mutex. Lock the mutex around the call to
> SetRenderCallback. When rendering upstream from the mixer, try to
> lock the mutex; if it fails, you know disconnection is in progress
> and can bail out. The realtime thread won't block because you're only trying
> to lock the mutex.
I think all I'd need to know is this:
Do the render callback as installed by a call to
AudioUnitSetProperty(mixerAudioUnit, kAudioUnitProperty_SetRenderCallback,
kAudioUnitScope_Input, chan, &callback, sizeof(AURenderCallbackStruct)
and the notification callback as installed by a call to
AudioUnitAddRenderNotify(mixerAudioUnit, myNotificationCallback, NULL);
run on the same thread or on different threads? To my understanding they
must run on the same thread because the notification callback is run
with kAudioUnitRenderAction_PreRender and kAudioUnitRenderAction_PostRender
flags, respectively, which implies to me that both callbacks are run by the
same thread.
It would be very helpful if you could provide a definitive answer here.
--
Best regards,
Andreas Falkenhahn mailto:[email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com
This email sent to [email protected]
