Rust Audio

Best Practices and Bad Ideas in Rust Audio?

Hi,

being a fairly seasoned C++ audio developer (it’s what I do for a living, basically), I’ve recently been getting into Rust audio development.

Now, in the C++ world, there’s some things you should keep in mind, which are well summarized in this rather famous article: http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

Basically, don’t do anything non-deterministic in the audio thread … no memory allocations, etc.

So I wonder how those things translate to Rust, and how I can write a balance between elegance and efficiency in Rust audio.

In my first Rust audio program (https://github.com/the-drunk-coder/wasm-loop-player), for example, I used fixed-sized arrays in a somewhat functional style. I wonder if it was more efficient to use a more old-fashioned C-Style and pass in the audio buffer to fill ? Those are the little questions I currently have …

I wonder what your thoughts on this are ?

Best,
N

1 Like

In my experience in rust, the same rules put forth in that article apply. The only difference being the language specific manor in which you could break those rules. Rust wraps up a lot of things that could break those rules in to convenient types that should be avoided in your critical section: Box, Rc, Arc, Mutex to name a few. The core philosophy that Ross Benica puts forth still holds true.

3 Likes

Some additions to @zyvitski’s excellent answer.
Rust leans heavily towards having data on the stack; I find that very convenient when doing audio programming.
For lock-free concurrency, there’s a PR for adding a true lock-free channel to the crossbeam crate, to be used in audio programming.