Re: 10.6.3 Open File Dialog preview stalling AUHAL (AudioQueue <->AUHal deadlock ?)
Re: 10.6.3 Open File Dialog preview stalling AUHAL (AudioQueue <->AUHal deadlock ?)
- Subject: Re: 10.6.3 Open File Dialog preview stalling AUHAL (AudioQueue <->AUHal deadlock ?)
- From: "Ross Bencina" <email@hidden>
- Date: Tue, 27 Apr 2010 01:12:36 +1000
Replying to my own message (see original message below for a description of
the fault)...
I have done some further investigation and am not really any wiser, but the
problem of the standard open file dialog wedging my AudioIOProc persists.
SpinControl indicates all relevant threads are stalled on CAMutex::Lock()
inside the HAL (see later in this post for a link to another SpinControl
dump). It looks like a CoreAudio bug to me. I'd appreciate some feedback on
this please. Is this a known issue? Should I file a bug? How can I work
around this?
I need to at least find a workaround to stop my app audio dying when the
user tries to select a sound file in the open file dialog. Is it possible to
stop the standard file dialog trying to load preview information on a
soundfile?
I could move my calls to
AudioDeviceGetProperty(kAudioDevicePropertyActualSampleRate) and
AudioDeviceGetProperty(kAudioDevicePropertyLatency) outside the AudioIOProc
on 10.6 but this will mess with my timing calculations (used for
synchronising audio with timecode etc) if either of these properties change
while the stream is active. I assume that the estimated actual sample rate
is updated somewhat regularly, and Jeff said a while back that
kAudioDevicePropertyLatency can change under some conditions. I'm actually a
bit surprised/frightened that AudioDeviceGetProperty is aquiring a Mutex.
Should I' be polling these properties in another thread? (not that that
would prevent the current deadlock entirely).
Here is the latest full SpinControl output:
http://www.audiomulch.com/downloads/AudioMulch204b4_SpinControl_20100427_0021.txt
The SpinControl output is generated when my App hangs when I try to close my
AUHAL instance from the main thread, but note that my AudioIOProc
(Thread_16866 in the trace) wedged (stopped generating audio) earlier while
the open file dialog was trying to populate its preview pane.
There are 9 (!) wedged QTMovie_AsyncLoadHelper threads, presumably created
by the standard open file dialog (cocoa version):
-[QTMovie_AsyncLoadHelper _loadMediaHelperOnBackgroundThreadWithAttributes:]
Certainly I didn't create them.
This looks like there is a HAL mutex which never gets unlocked. My
AudioIOProc is blocked inside AudioDeviceGetProperty (Thread_16866 linked in
trace above) and and one of those QT helper threads is blocked calling
AudioDeviceSetProperty (Thread_17490 in the trace linked above).
The other QT helper threads are blocked inside
AQIONodeManager::_FindAQIONode
Here's an older one:
http://www.audiomulch.com/downloads/AudioMulch204b4_SpinControl_20100419_1804.txt
That one has less blocked QTMovie_AsyncLoadHelper
_loadMediaHelperOnBackgroundThreadWithAttributes: threads.
Is it possible this is a runloop notification issue? The file dialog is a
Cocoa file dialog embedded in a Carbon app (yes I am calling
NSLoadApplication at startup).
The open file dialog preview pane doesn't stall if my AUHAL instance isn't
open.
My AUHAL instance is using the internal notification thread mechanism, this
one->
AudioObjectPropertyAddress theAddress = { kAudioHardwarePropertyRunLoop,
kAudioObjectPropertyScopeGlobal, kAudioObjectPropertyElementMaster };
OSStatus osErr = AudioObjectSetPropertyData (kAudioObjectSystemObject,
&theAddress, 0, NULL, sizeof(CFRunLoopRef), &theRunLoop);
Any ideas?
Thanks
Ross.
----- Original Message -----
From: "Ross Bencina" <email@hidden>
To: <email@hidden>
Sent: Monday, April 19, 2010 7:22 PM
Subject: 10.6.3 Open File Dialog preview stalling AUHAL (AudioQueue <->AUHal
deadlock ?)
Hi Guys
On 10.6.3 I'm having a problem with intermittent AUHAL audio stalling when
the open file dialog is preparing it's preview pane for the selected sound
file. When this happens, the preview pane displays the circular-dash
loader
animation instead of sound file details. I can reproduce this by getting
my
app generating a stream of audio, opening an open file dialog in my app
and
stepping through a bunch of sound files in a single directory with the
arrow
keys. Within a minute or two audio stalls and I get the loader animation.
I
can close the dialog, but then if I get my app to close the AUHAL stream
the
main thread stalls too. My customers have reported the same problem on
other
versions of SnowLeopard.
Looking at the (trimmed) SpinControl output below, it looks like a
deadlock on a
CoreAudio mutex.
Thread_53748 is my main thread trying to close down HAL
Thread_53927 is the ioproc thread which stalled after I selected a
soundfile
in the open file dialog
I suspect Thread_57760 is a background thread the open file dialog
launched
to prepare the preview information for the sound file selected in the
dialog -- certainly it's not one of mine.
Is this a known bug?
I notice I'm calling AudioDeviceGetProperty() from within the IOProc. I'm
not feeling too comfortable about that now, but my understanding is that
this is safe, isn't it? I'm using it to retrieve
kAudioDevicePropertyActualSampleRate and kAudioDevicePropertyLatency --
I'm
assuming these can vary from call to call, otherwise perhaps I can work
around this bug by moving them outside my IOProc.
Thanks!
Ross.
_______________________________________________
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