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 Armstrong <email@hidden>
- Date: Tue, 27 Feb 2018 02:16:44 +0000
As a related question, is there any reason not to just feed the audio
thread with a ringbuffer filled on a different thread? You could manage
pointers either with try-lock or atomics. It seems like this would be a
solution that's generic, lightweight, and extensible to most any
application. (And in practice, a try-lock shouldn't often fail, since the
critical section of a ring operation is so small)
Brian
On Mon, Feb 26, 2018 at 6:11 PM Brian Willoughby <email@hidden>
wrote:
> 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
>
_______________________________________________
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