# Considerations for real-time audio programming in C++

**URL:** <https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465>\
**Category:** General JUCE discussion\
**Created:** [December 6, 2017, 3:23pm UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465 "2017-12-06T15:23:03Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![CHenry](https://avatars.discourse-cdn.com/v4/letter/c/b487fb/32.png) [@CHenry](https://forum.juce.com/u/CHenry)\
**Post date:** [December 6, 2017, 3:23pm UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465/1 "2017-12-06T15:23:03Z")

</div>

Hi all!  
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.  
Cheers,  
Craig

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2017, 3:38pm UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465/2 "2017-12-06T15:38:00Z")

</div>

For starters, Timur’s talks cover most of the basics:

[![](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/7/70914c096f59f2fa3059e58592f8c2813d24c708.jpeg "CppCon 2015: Timur Doumler “C++ in the Audio Industry”") ](https://www.youtube.com/watch?v=boPEO2auJj4)

[![](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/c/c6a2675cb98302fc2b024464f188416678746fb8.jpeg "C++ in the Audio Industry, Episode II: Floating Atomics, Timur Doumler, JUCE Summit 2015") ](https://www.youtube.com/watch?v=2vmXy7znEzs)

---

<div class="post-metadata">

**Author:** ![CHenry](https://avatars.discourse-cdn.com/v4/letter/c/b487fb/32.png) [@CHenry](https://forum.juce.com/u/CHenry)\
**Post date:** [December 6, 2017, 4:10pm UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465/3 "2017-12-06T16:10:47Z")

</div>

Hi Jules,  
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.

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2017, 4:18pm UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465/4 "2017-12-06T16:18:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![CHenry](https://avatars.discourse-cdn.com/v4/letter/c/b487fb/32.png) [@CHenry](https://forum.juce.com/u/CHenry)\
**Post date:** [December 6, 2017, 4:42pm UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465/5 "2017-12-06T16:42:25Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2017, 4:44pm UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465/6 "2017-12-06T16:44:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jimc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jimc/32/16067_2.png) [@jimc](https://forum.juce.com/u/jimc)\
**Post date:** [December 7, 2017, 10:57am UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465/7 "2017-12-07T10:57:47Z")

</div>

This is a regularly cited intro you might want to look at too:  
[http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing](http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing)

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:

[http://futuretech.blinkenlights.nl/misc/cpumemory.pdf](http://futuretech.blinkenlights.nl/misc/cpumemory.pdf)  
[http://www.agner.org/optimize/#manuals](http://www.agner.org/optimize/#manuals)

---

<div class="post-metadata">

**Author:** ![CHenry](https://avatars.discourse-cdn.com/v4/letter/c/b487fb/32.png) [@CHenry](https://forum.juce.com/u/CHenry)\
**Post date:** [December 7, 2017, 2:15pm UTC](https://forum.juce.com/t/considerations-for-real-time-audio-programming-in-c/25465/8 "2017-12-07T14:15:19Z")

</div>

Thanks both, this is all really helpful
