Apple

You might find this thread useful if you haven't seen it already: https://lists.apple.com/archives/coreaudio-api/2010/Oct/msg00245.html (continues at https://lists.apple.com/archives/coreaudio-api/2010/Oct/msg00252.html).

I also found this post where Jeff Moore says that pthread_cond_signal is OK: https://lists.apple.com/archives/coreaudio-api/2009/Nov/msg00174.html. In this 2006 post he says that there "is a spin lock in the pthread implementation" (though I'm not completely sure that includes pthread_cond_signal) but that it very rarely causes problems: https://lists.apple.com/archives/coreaudio-api/2006/Jan/msg00044.html. I've been using Mach semaphores, which are also fine according to that post.

Kyle

On 19 May 2016 at 19:55, Michael Tyson <email@hidden> wrote:

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), itself a piece of code made available to the public as part of the Core Audio Utility Classes (https://goo.gl/RFMxcL).

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, 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

_______________________________________________
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