#Audulus 3 vs max code

#Audulus 3 vs max code

I see, you've changed from OSAtomicAdd32 that I saw in a previous version of your code to Atomics. If anyone is curious, or wants to tell me the hundreds of ways I've violated realtime safety via the swift runtime, my WIP code is here (new engine for a popular open source framework) AudioKit/Sources/AudioKit/Internals/Engine

Good idea is to count the number of glitches per a time interval to see how good / bad it works in practice. the data or code you are touching happen to be paged out and need to be loaded from disk - that's I/O → which can take unbound time (or just enough time to miss the deadline). Just remember some audio glitches are unavoidable even if you do it in C (e.g. In fact, the video that mentions avoiding Swift seems to have been removed from the archives (Session 501 WWDC 2017) and is quite hard to find now.ĭon't know the current official word on that, last time I paid attention it was: 'don't do this' in 2015 and 'yes you can' in 2016 (see the proof-links in the message above).

But no mention now of avoiding Swift explicitly. I see that AVFoundation's AVAudioSourceNode and AVAudioSinkNode released in 2019 both mention realtime audio processing applications with a caveat about avoiding mutexes and libdispatch. How realistic is it to use Swift for simple real-time audio processing today?