Re: Any system calls OK to use in audio thread?
Re: Any system calls OK to use in audio thread?
- Subject: Re: Any system calls OK to use in audio thread?
- From: Brian Willoughby <email@hidden>
- Date: Mon, 26 Feb 2018 18:11:03 -0800
I would be very surprised if memcpy() were on a list of functions that lock.
You should be able to call this (with the caveats mentioned in Ross’s article,
of course).
Note that memset() is only mentioned by Ross because it might take too long,
not because it might block. Ross is not suggesting that you merely avoid
calling memset() altogether, because rolling your own equivalent will surely
take as long or longer than the system function, resulting in the exact same
problem. What Ross is referring to here is that you should avoid designing
things that take too long. The focus here is not about functions that might
lock, but in avoiding an algorithm that can unpredictably take an inordinately
long amount of time. His suggestion is clearly to break up the operations so
that the time is spread out over several time slots, and therefore does not
take too much time in any single time slot. I’m certain that Ross would condone
calling memset() in the properly modified algorithm, because memset() on a
smaller amount of memory takes less time than memset() on a larger amount of
memory.
I do know that std::array will cause glitches. One of the students taking my
CoreAudio & AudioUnit course suffered from audio glitches until replacing
std::array with a pre-allocated Standard C array.
Personally, I would avoid all STL classes, but they’re obviously used by Apple
in the AudioUnit classes. If you absolutely must use STL, then look to Apple’s
example code as your guide. But be careful that it may not be immediately
obvious how Apple is avoiding the potential for locking in the way they’re
using the STL classes. It’s much safer to avoid STL unless you’re a complete
expert.
The vDSP functions are definitely safe for the audio thread. As Ross warns, be
sure that your algorithm does not take too much time - which is a separate
concern from avoiding functions that might block. vDSP functions will not
block. However, you can only perform a finite number of FFT or convolve
functions before you’ve exhausted the CPU.
dispatch_async() is completely different from vDSP. The fact that you should
not call dispatch_async() in the audio thread has nothing to do with vDSP. I
have never heard a glitch when using vDSP in an audio unit or CoreAudio
application.
Brian Willoughby
p.s. To state the issue from a different perspective: Just because you avoid
all functions that might block does not mean that your audio thread is
guaranteed not to glitch. Another cause of glitches is using too much CPU for
the audio buffer’s time slice. It’s easy to avoid functions that block - just
don’t use them in your code. The more difficult challenge is no using too much
CPU, because each computer model has a different amount of processing power per
audio time slice. The latter takes smart design skills followed by a lot of
testing on slower computers. Sometimes you just have to make a statement that
your audio software is not supported on certain slower models and move on.
On Feb 26, 2018, at 4:06 PM, Matt Ingalls <email@hidden> wrote:
> I have to admit that in the past i’ve done some dubious things inside the
> audio thread -- and i’m not proud of it.. ;)
>
> But in some recent C++ work, I'm not letting myself call any function I’m not
> absolutely sure is lock-free.
>
> Ross Bencina’s article is still my go-to-reference:
> http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing
>
> But now I’m wondering if I’m being too anal...
>
> Could I at least call memcpy and memset?
> And although I haven’t used any STL classes, maybe std::array might be safe
> to use?
>
> I am however calling some vDSP functions. I assumed they were intended to be
> used in real-time threads,
> but I actually can’t find anything that confirms this in the documentation -
> it does say it uses GCD,
> and I seem to recall a WWDC video
> https://developer.apple.com/videos/play/wwdc2015/508/?time=2952
> where Doug Wyatt says you shouldn’t even be calling dispatch_async() in the
> audio thread, so I don’t know..??
>
> Any thoughts would be appreciated.
>
> Thanks,
> Matt
_______________________________________________
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