Is it dangerous to call AudioDeviceGetProperty() from within a AudioHardwarePropertyListenerProc?
Is it dangerous to call AudioDeviceGetProperty() from within a AudioHardwarePropertyListenerProc?
- Subject: Is it dangerous to call AudioDeviceGetProperty() from within a AudioHardwarePropertyListenerProc?
- From: Jesper Papmehl <email@hidden>
- Date: Tue, 18 Jan 2005 16:58:28 +0100
Hi!
I sometimes get what appears to be a deadlock in my app when I change
the sample rate of the audio device I'm using.
I change the sample rate by calling
SetDevicePropertyStreamBasicDescription() from the main thread. I have
previously installed a property listener that listens to various
property changes (kAudioDevicePropertyStreamConfiguration and some
others). In my property listener I (among other things) get the values
of a bunch of properties like kAudioDevicePropertyStreams,
kAudioStreamPropertyDirection and kAudioDevicePropertyDeviceIsRunning.
In some cases (but not always) when I change the sample rate, my app
hangs. When I sample my hung app, I see that the UI thread hangs inside
SetDevicePropertyStreamBasicDescription, in a call to
semaphore_wait_signal_trap. One of the CoreAudio threads also appears
to have hung inside my property listener in a call to either
AudioDeviceGetPropertyInfo or AudioDeviceGetProperty (I don't see the
CoreAudio function names in my backtrace) which in turn eventually
calls semaphore_wait_signal_trap.
So, my question is, is it forbidden to call
AudioDeviceGetProperty[Info] in a property listener callback? Or does
anyone have any other idea what I might be doing wrong?
Thanks!
/Jesper Papmehl
Propellerheads
_______________________________________________
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