Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Jeff Moore <email@hidden>
- Date: Wed, 24 May 2006 11:45:43 -0700
Mr. Wexler is absolutely correct. The HAL makes no particular
guarantees about on which thread a particular property's listener
will get called. Most are called from the notification thread.
Several others are called on the thread that called Audio*SetProperty
(). A small few are called from the app's main thread. And there are
two special cases, kAudioDevicePropertyDeviceIsRunning and
kAudioDeviceProcessorOverload, that are currently always called from
the IO thread.
So in general, it is a bad idea to make assumptions about what thread
a property listener will get called on when dealing with the HAL.
Even the two special cases, kAudioDevicePropertyDeviceIsRunning and
kAudioDeviceProcessorOverload, may change thread contexts as the HAL
evolves over time.
On May 23, 2006, at 9:11 PM, Shaun Wexler wrote:
On May 23, 2006, at 8:25 PM, Steve Checkoway wrote:
Shaun Wexler wrote:
Beware: start/stop and other HAL notification callbacks may be
sent on arbitrary threads, often one of the IOProc threads. Do
not assume or rely on them being delivered on the dedicated
notification runloop thread. ;)
Surely it can't be sent on a an arbitrary thread! If it tried to
deliver a notification on thread 2 (in this case) it'd be in a for
a shock as there is no runloop being run. I could see it happening
on an arbitrary thread that the HAL owns or one I've told it to use.
Yes, it will. By arbitrary, I mean: any thread which calls [a
function which calls] a HAL function, the main thread and/or the
dedicated notification runloop thread, or any IOProc realtime
thread. You must be fully prepared in your callback handlers that
the function is executing on a realtime thread (often these will be
start, stop, and almost always for overloads). There are no
guarantees that your callback handler will be called on the runloop
thread that you've specified, and you must code defensively. These
are often the causes of "random CoreAudio bugs" which are in fact
blatant app bugs due to threading naïveté. Unfortunately this is
the way the HAL needs to behave; I think the documentation could
use some improvements in these areas.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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