Recovering gracefully from AUv3 crash
Recovering gracefully from AUv3 crash
- Subject: Recovering gracefully from AUv3 crash
- From: Martin Hairer via Coreaudio-api <email@hidden>
- Date: Thu, 18 Jun 2020 16:55:56 +0100
Hi,
I am in the process of porting my AU host from the AUv2 to the AUv3 API and,
since AUv3 Audio Units run in a separate process, I was hoping to be able to
recover gracefully from plug-in crashes. If memory serves well, this was even
one of the advantages of AUv3 touted by Apple when they were first introduced a
few years back.
Unfortunately, a few days of experimentation have left me rather frustrated.
What seems to happen is that if an AUv3 effect crashes in the middle of
processing audio, then its renderBlock gets stuck forever on a semaphore
waiting for a signal that never comes. This would be bad enough by itself, but
has the rather nasty side effect of causing a deadlock as soon as the host
sends pretty much any message to the AUAudioUnit instance, including trying to
release it or to invalidate its resources. Note that Apple's own AUv3Host
sample code freezes when faced with a crashing AUv3 Audio Unit.
My current workaround is to detect the crash by listening to
kAudioComponentInstanceInvalidationNotification and then leak the AUAudioUnit
object on purpose and ask the user to relaunch the application. This seems to
work but is clearly a horrible hack. So my question is whether anyone with
experience hosting AUv3 effects knows how to gracefully recover from a crash of
the effect without creating unwelcome side effects like blocked threads /
leaked objects / etc?
Thanks a lot! Best,
Martin
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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