A co-worker moved some code onto a separate thread. Doing so took
some of our audio input code off the main thread as well, something
that I would have thought was okay. But I was wrong.
Every so often the problem arises right after we've taken hog mode
successfully. You can see in the stack of the work thread:
AudioDeviceSetProperty >> HALObject::SetPropertyData >>
HALPlugIn::ObjectSetPropertyData >>
IOA_SingleDevice::SetPropertyData >> HP_HogMode::Take >>
IOA_SingleDevice::HogModeStateChanged >> CAMutex::Lock >>
pthread_mutex_lock >> semaphore_wait_signal_trap
Over on the main thread, you see the following in the stack:
CFRunLoopRunSpecific >> __CFMachPortPerform >>
IOA_HWDevice::MachPortCallBack >>
IOA_SingleDevice::HWDevice_FormatChanged >> CAMutex::Lock >>
pthread_mutex_lock >> semaphore_wait_signal_trap
Can you post a sample trace with the full backtraces?
Some questions that occurred to me, partially based on conjecture:
Why is the IOA_SingleDevice notifying itself?
Not sure what you mean. The HAL is written in C++ and the back trace
just shows the control flow moving between various implementation
objects.
Why is Hog mode being notified as a format change?
It is not. You are presuming that the two are related rather than just
coincidental.
Is the same CAMutex instance used in both IOA_SingleDevice methods?
What am I doing wrong?
Hard to say without more context.
--
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:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden
