Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Jeff Moore <email@hidden>
- Date: Mon, 22 May 2006 12:53:06 -0700
On May 22, 2006, at 12:43 PM, Steve Checkoway wrote:
On May 22, 2006, at 12:19 PM, Jeff Moore wrote:
Do you have a sample trace of the hang? It's hard to diagnose a
hang without one. Sometimes it's hard even when you have one =)
I do indeed!
Technically, these look like backtraces generated by gdb. This will
give you a very limited view on the hang. The sample tool gives a
more complete picture because it samples the backtraces of all the
threads in the process repeatedly over time to generate a histogram.
The net result is that it is generally much clearer as to which
threads are actually hung and which are just in the middle of a
system call or something like that.
Thread: Main thread
9002c128: semaphore_wait_signal_trap (libSystem.B.dylib)
90001948: pthread_mutex_lock (libSystem.B.dylib)
91479508: AudioHardwareGetPropertyInfo (CoreAudio)
914939ec: HP_PlugIn_Teardown(AudioHardwarePlugInInterface**)
(CoreAudio)
91493824: HP_PlugIn_Teardown(AudioHardwarePlugInInterface**)
(CoreAudio)
9149fb14: HP_PlugIn_DeviceStop(AudioHardwarePlugInInterface**,
unsigned long, long (*)(unsigned long, AudioTimeStamp const*,
AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*,
AudioTimeStamp const*, void*)) (CoreAudio)
9149fa50: AudioDeviceStop (CoreAudio)
9149f9b4: AudioDeviceStop (CoreAudio)
001630dc: RageSound_CA::~RageSound_CA()
0016301c: RageSound_CA::~RageSound_CA()
0001ab60: RageSoundManager::Shutdown()
00055b78: ShutdownGame()
00058560: SM_main
00258f8c: -[SMMain startGame:]
92976194: forkThreadForFunction (Foundation)
9002ba68: _pthread_body (libSystem.B.dylib)
Looks like the main thread is blocked in AudioDeviceStop(). It most
likely is blocked on the mutex that is used to syncrhonize against
the IO thread.
Thread: HAL I/O thread
9002c1a8: swtch_pri (libSystem.B.dylib)
fff80000:
9148c674: HP_PlugIn_ObjectSetPropertyData
(AudioHardwarePlugInInterface**, unsigned long,
AudioObjectPropertyAddress const*, unsigned long, void const*,
unsigned long, void const*) (CoreAudio)
9149bcb0: AudioObjectPropertiesChanged (CoreAudio)
9149b75c: AudioObjectPropertiesChanged (CoreAudio)
9148c5dc: HP_PlugIn_ObjectSetPropertyData
(AudioHardwarePlugInInterface**, unsigned long,
AudioObjectPropertyAddress const*, unsigned long, void const*,
unsigned long, void const*) (CoreAudio)
9002ba68: _pthread_body (libSystem.B.dylib)
This backtrace looks odd. It definitely doesn't look like an IO
thread usually looks. There are all sorts of stack frames missing.
Either this isn't the IO thread or gdb stopped at a time where the
thread's stack was in a strange state.
Hmm, looks like my backtracing code didn't know about the HAL's
notification thread. I'll have to grab the trace from gdb when I
get back to that computer. I was wrong when I wrote earlier that
AudioDeviceStop was being called multiple times. This behavior
happens when I change the device sample rate using Audio MIDI Setup
and then quit (which calls AudioDeviceStop for the first and only
time). If I don't change the sample rate, when I quit I'm getting a
crash in pthread_body but I don't remember in which of the HAL's
threads that happens. Again, I'll check when I get back to that
computer this evening.
I'd try to get a sample trace of the hang too. You'll get more info
about the hang that way.
--
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