IMHO real-time audio processing stays near to game development in terms of performance.
So I share it because this lecture may be useful for all who writes audio processing software.
Yes, it's good, especially for those who start to writing audio processing code.
Note how many modern C++ facilities is used in the slides.
Not too much. No exceptions, no new/delete, no STL and Boost in real-time code.
Also I know the better way to implement exchange between threads rather than using shared_ptr and atomics. The only thing that is really needed is atomics. But they may be implemented in other way by writing 10-20 lines of corresponding assembly code.
Yeah, that's some good stuff. In a nutshell, use C++ for convenience, but basically write C.
Anecdote #1: I had a realtime C++ program with modest STL usage (vectors and judicious use of maps, strings, streams). Valgrind showed me that STL methods were burning up the cache. The program is fast enough but it could easily be twice as fast/efficient, which would be nice for slower machines (and laptop batteries).
Anecdote #2: I was porting some JS graphics code to C++, lots of point arrays like [ [x1, y1], [x2, y2], ... ] which is pretty inconvenient for plain C APIs like OpenGL. So I switched to flat interleaved arrays [ x1, y1, x2, y2, ... ] like you see in a lot of old graphics algorithms. That's an efficient format for CPUs/GPUs. It actually worked better in Javascript too; that language lacks pointers/references, but this way I can reference an x,y pair by array index.