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: Andreas Falkenhahn <email@hidden>
- Date: Tue, 29 Nov 2016 18:10:16 +0100
On 29.11.2016 at 07:46 Brian Willoughby wrote:
> 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.
Ok, so I guess you're talking about the AudioObjectAddPropertyListener()
API? There doesn't seem to be any documentation available on this
function and the things the list archives reveal are beyond me.
What property should I listen to using this API? Who is even guaranteeing
anything if everything is undocumented? It all sounds like black magic
to me with no clearly defined documentation at hand.
> The render notification callback is certainly not safe, because it
> allows the option of manipulating the audio data.
Well, but at least it's documented and to me the documentation sounds
like that it is safe to assume that MixerInputCallback() and the
render notification callback aren't allowed to run simultaneously.
If that is the case, I think my current solution should do the
trick. Although it's kludgy, but so is Core Audio IMHO ;)
> 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?
Actually, I've forgotten much about Core Audio. I wrote the code I'm now
trying to fix more than 11 years ago on 10.4 on PowerPC. I think the code
is pretty fine because it still works on PPC/x86/x64 and iOS so I'd rather
not touch/rewrite major parts of it because it was quite a lot of work
to get this done.
As I said, the fix outlined in my last mail (cf. above) seems to solve
the problem of being able to safely dispose of the audio converter. I've
run hard-core stress tests on that code and there were no crashes so I
*think* it is good. If you can prove otherwise, please let me know.
> 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?
No, how should I? There's no documentation whatsoever, there are dozens
of properties in the headers, I honestly haven't got the slightest idea
where to start or what to do.
--
Best regards,
Andreas Falkenhahn mailto: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