Re: best way to divert callbacks to main thread from audio thread
Re: best way to divert callbacks to main thread from audio thread
- Subject: Re: best way to divert callbacks to main thread from audio thread
- From: Kyle Sluder <email@hidden>
- Date: Mon, 03 Oct 2011 09:18:22 -0700
On Oct 3, 2011, at 6:52 AM, Rich E <email@hidden> wrote:
> Hi all,
> I'm working on a project that is using a c library for audio
> processing in iOS via audio units. We have a few callbacks that are
> scheduled from the C library on the audio thread, but need to be
> delivered on the main thread for UI updates, some with signatures that
> have up to three arguments.
>
> Obviously, we want to spend as little time on the audio thread to call
> these and we want to allocate as little memory as possible while doing
> so (although we will have to allocate some...). I was wondering what
> people here would suggest as the preffered approach. So far our
> options look like:
>
> 1) use NSObject's - (void)performSelectorOnMainThread:(SEL)aSelector
> withObject:(id)arg waitUntilDone:(BOOL)wait
> - this isn't so nice for us, as we'd have to allocate an NSArray and
> pack all the other arguments in it (one of which can be a variable
> length NSArray), and also unpack on the other end.
>
> 2) use NSInvocation's performSelectorOnMainThread and pack it with the
> callback's arguments, something along the lines of:
> http://goodliffe.blogspot.com/2011/01/ios-performselectoronmainthread-with.html
>
> 3) use GCD's dispatch_async(dispatch_get_main_queue(), ^{ ... callback..}).
> - I've read on this list on two different posts that this is not
> recommended for the reason that dispatch_async allocates memory, but
> it is still my favorite (and most elegant) solution. I was actually
> able to test arrays up to length 50k elements while still maintaing a
> perfect tone generator output, although I haven't tested it with
> anything more complex.
>
> I'd love to hear any advice they have to share, if they know of a
> different solution to consider, etc.
Unfortunately, all three of your proposed solutions are incorrect, as they can all attempt to allocate memory and therefore block on the malloc lock.
The rule of thumb is that you don't do any calling from your callback thread. You dump your data into the buffers and get out ASAP.
If other threads need access to the data produced by your render callback thread, locklessly copy that information to a place where the UI thread can pick it up. But don't attempt to call out to your UI thread from your audio callbacks.
--Kyle Sluder _______________________________________________
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