Re: How to safely dispose of audio converter
Re: How to safely dispose of audio converter
- Subject: Re: How to safely dispose of audio converter
- From: Brian Willoughby <email@hidden>
- Date: Mon, 28 Nov 2016 22:46:12 -0800
On Nov 28, 2016, at 6:59 AM, Andreas Falkenhahn <email@hidden> wrote:
> On 28.11.2016 at 00:18 Brian Willoughby wrote:
>> CoreAudio is multi-threaded, and the calls you're dealing with are
>> asynchronous. That means other threads can still be in the process
>> of accessing resources even after your calls to disconnect the resources have returned.
>
>> What you need to do is register for one or more property change
>> notifications. CoreAudio will then call your notification callbacks
>> when the audio threads have finished with your requested changes.
>
> But I don't see how this can solve the problem. I've already registered
> a render notification callback using AudioUnitAddRenderNotify(). This
> allows me to get notified on pre/post render but the fundamental problem
> remains: the notification callback also runs on the audio I/O thread
> and this thread mustn't block. Hence, AFAICS, there is no way to stop the
> audio renderer from this notification callback.
Your "render notification callback" is not the same thing as a "property change notification." Search through the archives of this mailing list for previous discussions. The accepted procedure for starting up, changing, or shutting down many CoreAudio specifics (like sample rate, etc.) requires that your application wait for the matching property change notification to occur before you manipulate any pointers or critical data that is used in the audio thread.
The render notification callback is certainly not safe, because it allows the option of manipulating the audio data.
I can't recall which thread the property change notifications occur on - probably the same thread as the one that registered for the callback - but my main point is that these are separate API that you don't seem to be using in your code at all, at least not yet.
>> As one example, I assume that you must have called Start on the
>> Output AU in order to get your callback working. You should probably
>> then call Stop on the same Output AU in order to cease the callback.
>
> That won't work in my case because multiple channels (busses) are involved.
> If I call AUGraphStop(), all those busses will stop playback. However,
> I only want one particular bus to cease playback.
>
> What do you think of the following implementation?
>
> 1. The main thread sets a flag that a bus is to be killed. It then waits
> for another flag from the notification callback.
>
> 2. When I get a kAudioUnitRenderAction_PostRender notification for that bus,
> the notification callback sets another flag which both the main thread
> and the MixerInputCallback() check.
>
> 3a. When the main thread sees this flag, it will dispose of the audio
> converter.
>
> 3b. When MixerInputCallback() sees the flag, it will do something like the
> following:
>
> *inActionFlags = kAudioUnitRenderAction_OutputIsSilence;
> memset(ioData->mBuffers[0].mData, 0, ioData->mBuffers[0].mDataByteSize);
> return noErr;
>
> I think this would be a safe way to dispose of the audio converter because
> as soon as the second flag is set, I can be sure that the audio converter
> object will no longer be accessed by MixerInputCallback().
>
> I've tested it and it seems to work fine. But of course this solution is not
> what I would call "elegant". That's why I'm wondering whether Core Audio doesn't
> offer any nicer solutions to this particular problem…
Are you aware that Apple's mixer AudioUnits allow you to enable and disable input elements without needing to manipulate render callbacks or anything that drastic?
In your previous example, you were changing the render callback to NULL, and I was suggesting that you register for a property change notification for the render callback property. Did you try that? Because property changes are not synchronous, you cannot rely on the order of your program execution unless you're also listening to the proper notifications.
Brian Willoughby
Sound Consulting
_______________________________________________
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