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: Jeff Moore <email@hidden>
- Date: Mon, 26 Apr 2010 09:26:04 -0700
This is an application bug. The spin trace shows that the IOProc is calling AudioDeviceGetProperty(). This call, like every other HAL API call, blocks. So it cannot be made from your IOProc without things like this happening.
To fix this, your app needs to be caching what it needs from the HAL prior to the IOProc getting called.
On Apr 26, 2010, at 8:12 AM, Ross Bencina wrote:
> 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
--
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