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 protected]> 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 protected]> 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 protected]) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/coreaudio-api/brian.armstrong.ece%40gmail.com > > This email sent to [email protected] >
_______________________________________________ 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]
