Hi folks, I noticed recently that the AUAudioFilePlayer audio unit is using pthread_cond_signal from its render function, via CAGuard::Notify (http://goo.gl/VErpxz <http://goo.gl/VErpxz>), itself a piece of code made available to the public as part of the Core Audio Utility Classes (https://goo.gl/RFMxcL <https://developer.apple.com/library/ios/samplecode/CoreAudioUtilityClasses/Listings/CoreAudio_PublicUtility_CAGuard_cpp.html>).
I always thought pthread_cond_signal was a no-no for use on the audio thread due to the risk of priority inversion; this post from way back in 2002 reports that pthread_cond_signal can block http://goo.gl/DwFYUq <http://goo.gl/DwFYUq>, although I’ve not followed up on the findings. Consequently, I’ve always used polling, rather than a condition variable or semaphore, but this can cause a bit of lag, or an awkward amount of CPU consumption. Is the presence of pthread_cond_signal in CAGuard and AUAudioFilePlayer an indication that this is now safe? Many thanks, Michael -- Michael Tyson | atastypixel.com Loopy: Record, loop, layer. Like a pro. http://loopyapp.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
