RE: audio unit deinstantiation thread
RE: audio unit deinstantiation thread
- Subject: RE: audio unit deinstantiation thread
- From: Jeremy Todd <email@hidden>
- Date: Thu, 14 Jul 2011 18:24:49 -0400
I couldn't find anything in the documentation about this either.
The specific problem is that we're installing a run loop timer when we're instantiated. This is because our DSP needs regular callbacks from a non-audio thread (there are what I believe to be good reasons for this, but it's pretty involved so I'll leave the explanation out of this email thread). We can't safely remove a run loop timer from a thread it's not running on, so shutting down safely in this case is trickier than I thought it should be.
Are there any calls in the Audio Unit itself (as opposed to its view) which have strong guarantees that they'll happen on the main thread?
I can see how it's natural to write hosts that don't use the main thread to interact with (the non-view part of) Audio Units at all (indeed one of our own hosts behaved this way for a while during development), but it's really difficult to do some things in plug-ins with no guarantees at all about what thread you're on.
Regards,
Jeremy
> -----Original Message-----
> From: Paul Davis [mailto:email@hidden]
> Sent: Wednesday, July 13, 2011 10:32 AM
> To: Jeremy Todd
> Cc: email@hidden
> Subject: Re: audio unit deinstantiation thread
>
> On Wed, Jul 13, 2011 at 10:18 AM, Jeremy Todd <email@hidden> wrote:
> > Hello,
> >
> > We recently noticed that Soundtrack Pro 3.0.1 is instantiating our plug-ins on the main thread, but in some cases (Render to Action)
> deinstantiating them on a different thread. This is not something our plug-ins expect, and I'm wondering if it's considered a valid host
> behavior?
> >
> > We're also seeing that the component representing our Audio Unit is closed before our UI is deallocated (we have a Cocoa view in
> this case). This is also unexpected, although much easier to work around than the above behavior.
>
> Neither aspects are documented, since basically, being an AU host is almost completely undocumented. I can tell you that both
> Ardour and Mixbus will close your AU component before deallocating the GUI in almost all cases. We will also make no conscious
> effort to deinstantiate the plugin in the same thread as the one it was instantiated in, but given that there's no way to delete a plugin
> via MIDI or OSC control, it will generally happen in the GUI thread that created the plugin. I would consider entirely valid to do this in
> another thread, and you won't find anything from Apple that says anything about this.
_______________________________________________
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