I’m currently in the last year of my degree. I’m writing a paper on practical considerations for real-time audio programming in C++. I’m hoping to get some practical insight from audio professionals. It would be great to hear what people take into consideration whilst writing real-time audio applications and if they have any specific workflows or techniques they employ to ensure audio callbacks are met.
For starters, Timur’s talks cover most of the basics:
Yeah, I’ve found those to be really useful. Additionally, Pete Goodliffe’s talk covers some of the same topics. The ADC talks have been a great resource.
It would be great to hear if you had anything else to add. I’m also interested in the practicalities of ensuring that any processing is executed fast enough provided that the code is lock-free and the algorithms used are well-suited. I started programming last year and everything I’ve written thus far has not had the constraints inherent in real-time programming.
Not sure what general advice I could add that isn’t already covered in these talks…
The main thing to do is to eliminate the stuff that will take an indeterminate amount of time to run - i.e. anything that could lock - and then what’s left should at least be predictable, so profiling it will let you see where the hotspots are that you need to work on. Then you’re just down in the weeds, trying to get the compiler to optimise and vectorise nicely.
Okay great thanks. Also I was wondering what things you might think about when choosing algorithms? I understand that considering the worst case scenario is important to ensure that it’s predictable. Are there any other characteristics that are desirable?
Well, understanding big-O algorithm performance characteristics is important, but TBH in an audio processing function it’s unlikely you’ll find yourself writing much O(n^2) code. You should be aware of algorithm scalability though, of course.
This is a regularly cited intro you might want to look at too:
If you want to get onto general optimisation:
Thinking about what’s in the cache, what’s in the registers probably useful.
It’s useful to have a vague handle on assembly so you can validate what’s actually happening.
If you want to nerd out a bit:
Thanks both, this is all really helpful