Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Steve Checkoway <email@hidden>
- Date: Mon, 22 May 2006 12:43:10 -0700
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!
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)
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)
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.
No, it actually doesn't since that comment is specifically
referring to the "stopped state" of the IO thread's logic which is
different than the thread actually stopping.
Ah, the distinction is clear now.
The point I'm trying to get across here is that it does not matter
if the current implementation of the HAL does or does not call the
IOProc after AudioDeviceStop() returns. What matters is that the
behavior is not guaranteed and should not be relied on. Knowing
this, you should take appropriate precautions against re-entrancy
in your code.
Noted. Thank you for clearing this up.
- Steve
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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