Re: Deadlock on HP_HogMode::ChangeNotification
Re: Deadlock on HP_HogMode::ChangeNotification
- Subject: Re: Deadlock on HP_HogMode::ChangeNotification
- From: Jeff Moore <email@hidden>
- Date: Thu, 04 Sep 2008 12:27:57 -0700
On Sep 4, 2008, at 12:12 PM, Felix Schwarz wrote:
Thanks for your reply!
What I don't understand is this: what adds the observer for the
CFNotification into my main thread?
The HAL does this. It is a side effect of the fact that it is using
CoreFoundation for hog mode notifications. CF doesn't provide a way
for the HAL to shunt that activity off to it's own notification
thread. Rather, it forces the notifications to always happen on the
app's main thread.
Does this happen purely by linking against the Core Audio framework?
It happens when your app or any of the APIs it calls initialize the
HAL by calling any of the HAL's API.
Or can it be a side effect of calling any of the following functions
(all of which I'm using) from the main thread?
-- snip --
AudioHardwareGetPropertyInfo
AudioHardwareGetProperty
AudioHardwareSetProperty (only setting these properties:
kAudioHardwarePropertyDefaultInputDevice,
kAudioHardwarePropertyDefaultOutputDevice,
kAudioHardwarePropertyDefaultSystemOutputDevice)
AudioDeviceGetProperty
AudioDeviceGetPropertyInfo
-- snap --
Since all I do is polling a list of currently available devices,
their stream configuration and their default device status, I could
easily factor that code out to a small external helper tool that
communicates through pipes with my main application. If there's,
however, anything I can do to avoid the necessity for that, I'd of
course prefer that route.
If you are on Leopard, you can use the AudioHardwareServices API
(which can be found in <AudioToolbox/AudioServices.h>) to do all of
that. AHS is essentially a way to access the non-IO parts of the HAL's
API via RPC calls. This was introduced in Leopard, so you'd still need
to do something different for earlier systems.
However as I mentioned above, if you are using any API that touches
the HAL (e.g. opening an instance of the AUHAL AudioUnit, using an
AudioQueue, calling NSSound, etc.), you will still end up with the HAL
getting initialized in your process. So, using an RPC mechanism
wouldn't actually help you in that case.
Am 02.09.2008 um 23:32 schrieb Jeff Moore:
It appears that what is happening here is that some other
application is releasing/acquiring hog mode while at the same time
a configuration change, like a format change, is coming in. This
can happen when the DVD Player is staring/stopping AC-3 playback.
You should definitely file a bug about this. In the meantiem, I'm
not aware of any work around that you can take to avoid a deadlock
like this.
On Sep 2, 2008, at 12:30 PM, Felix Schwarz wrote:
Hello,
I've been getting a few reports of deadlocks of my application
lately.
I have asked the affected users to send me an Activity Monitor
Analyze-log and all of the deadlocks seem to occur after a
CoreAudio-callback is called following the receipt of what -
judging by the log - looks like a CFNotification:
-- cut --
1962 Thread_2503
1962 0x31e5
1962 0x32be
1962 0x33ab
1962 NSApplicationMain
1962 -[NSApplication run]
1962 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
1962 _DPSNextEvent
1962 BlockUntilNextEventMatchingListInMode
1962 ReceiveNextEventCommon
1962 RunCurrentEventLoopInMode
1962 CFRunLoopRunInMode
1962 CFRunLoopRunSpecific
1962 __CFMachPortPerform
1962 __CFXNotificationReceiveFromServer
1962 __CFXNotificationHandleMessage
1962
HP_HogMode::ChangeNotification(__CFNotificationCenter*, void
const*, __CFString const*, void const*, __CFDictionary const*)
1962
IOA_SingleDevice::HogModeStateChanged()
1962
IOA_SingleDevice::RefreshAvailableStreamFormats()
1962
IOA_Stream::RefreshAvailablePhysicalFormats()
1962 CAMutex::Lock()
1962 pthread_mutex_lock
1962
semaphore_wait_signal_trap
1962
semaphore_wait_signal_trap
1962 Thread_2603
1962 thread_start
1962 _pthread_start
1962 select$DARWIN_EXTSN
1962 select$DARWIN_EXTSN
1962 Thread_2703
1962 thread_start
1962 _pthread_start
1962 CAPThread::Entry(CAPThread*)
1962 HALRunLoop::OwnThread(void*)
1962 CFRunLoopRunInMode
1962 CFRunLoopRunSpecific
1962 mshMIGPerform
1962 _XAHS_PropertyListener
1962 Server_AHS_PropertyListener
1962
HALDefaultDevice::PropertyListener(unsigned long, unsigned long,
AudioObjectPropertyAddress const*, void*)
1962 HALObject::PropertiesChanged(unsigned
long, AudioObjectPropertyAddress const*)
1962 AUGenericOutputEntry
1962 AUGenericOutputEntry
1962 AUGenericOutputEntry
1962 0x7000b3dc
1962 AUGenericOutputEntry
1962 AUGenericOutputEntry
1962 AudioDeviceSetProperty
1962
HALObject::SetPropertyData(AudioObjectPropertyAddress const&,
unsigned long, void const*, unsigned long, void const*,
AudioTimeStamp const*)
1962
HALPlugIn::ObjectSetPropertyData(HALObject const&,
AudioObjectPropertyAddress const&, unsigned long, void const*,
unsigned long, void const*, AudioTimeStamp const*)
1962
HP_HardwarePlugIn_ObjectSetPropertyData
(AudioHardwarePlugInInterface**, unsigned long,
AudioObjectPropertyAddress const*, unsigned long, void const*,
unsigned long, void const*)
1962
IOA_SingleDevice::SetPropertyData(AudioObjectPropertyAddress
const&, unsigned long, void const*, unsigned long, void const*,
AudioTimeStamp const*)
1962
IOA_Device::SetPropertyData(AudioObjectPropertyAddress const&,
unsigned long, void const*, unsigned long, void const*,
AudioTimeStamp const*)
1962
HP_Device::SetPropertyData(AudioObjectPropertyAddress const&,
unsigned long, void const*, unsigned long, void const*,
AudioTimeStamp const*)
1962
HP_Device::ExecuteCommand(HP_Command*)
1962
IOA_Device::StartCommandExecution(void**)
1962
CAMutex::Lock()
1962
pthread_mutex_lock
1962
semaphore_wait_signal_trap
1962
semaphore_wait_signal_trap
-- cut --
What could be causing this? And what could add an observer for
said CFNotification to my application's runloop?
I don't register for Core Audio callbacks / don't register any
Core Audio Property Listeners anywhere in my code. I only use Core
Audio to get and set the current default audio output and input
devices.
Any help or insight on what could cause this would be greatly
appreciated.
--
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