Re: AudioQueueNewOutput causes gui to lock up
Re: AudioQueueNewOutput causes gui to lock up
- Subject: Re: AudioQueueNewOutput causes gui to lock up
- From: Kyle Sluder <email@hidden>
- Date: Mon, 24 Sep 2012 20:40:21 -0700
On Mon, Sep 24, 2012, at 08:21 PM, Brian Hall wrote:
> Thanks Kyle,
>
> Does that mean I need to create a new thread to run the audio queue in?
Not necessarily. Each NSRunLoop wraps a CFRunLoop, so you can pass the
main thread's CFRunLoop to AudioQueueNewOutput to get your callbacks
invoked on the main thread.
However, I'm not sure if this is a desirable approach, since it subjects
your audio queue to the unpredictability of main thread GUI event
processing. AudioQueueNewOutput allows you to pass NULL, which results
in your callback being executed on an (unpredictably random) internal
thread, or you can spawn your own thread and use _its_ runloop (every
thread has exactly one runloop that is created on-demand when you
request it with +[NSRunLoop currentRunLoop] or CFRunLoopGetCurrent).
If you pass NULL for the runloop, the thread your callback is invoked on
_might_ be a hard real-time thread; I can't remember. If so, your
callback _must_ be FAST. The data should already be computed, and your
callback mustn't take out any locks or spend too much time doing
anything other than swapping pointers. In a normal (non-realtime)
thread, you must still be fast or else your audio will glitch, but the
constraints are slightly relaxed. You won't cause thread death by taking
too long, for example.
--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