UI thread Blocked in AudioOutputUnitStop (Correction)
UI thread Blocked in AudioOutputUnitStop (Correction)
- Subject: UI thread Blocked in AudioOutputUnitStop (Correction)
- From: Philippe Wicker <email@hidden>
- Date: Sun, 19 Oct 2003 11:26:29 +0200
Hi all,
I realized that my last message on the same subject was not very clear.
Here is a (hopefully) better version :-))
I've encountered a weird AudioOutputUnitStop API behavior (Jaguar
10.2.8). The thread (the main and UI thread in this case) stay blocked
in the call to AudioOutputUnitStop() if the IO thread is itself
waiting on a semaphore (a POSIX semaphore in this case).
The debugger frame window for the UI thread shows the following call
sequence (showing only the last calls from older to newer)):
AudioDeviceStop
HALPluginDevice::StopIOProc
HPPluginDeviceStop
HPDevice::DoStopIOProc
HPDevice::ExecuteCommand
IOADevice::StartCommand
CAGuard::Lock
pthread_mutex_lock
semaphore_wait_trap
The last call is usually displayed when the calling thread attempts to
lock a mutex which is already locked.
The debugger frame window for the IO thread shows the following call
sequence (last calls only, from older to newer)):
// CoreAudio code
AudioUnitBaseRender
AUBase::DoRender
// My code
HostInsert::Render
ASRemoteRender
AT::AudioClient::RemoteRender
AT::ATAudioInputStub::Render
AT::SemaphoreWait
// The POSIX call
sem_wait
The IO Thread is blocked in sem_wait because of a bug in my apps, I
have to fix it but it is not the issue here. It looks like a mutex is
taken (locked) by the CoreAudio (or some other system) code when
entering the render cycle and unlocked when exiting the render cycle.
Is this the expected behavior or should I consider this as a bug ?
Thanks,
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.