Rust Audio

Best Practices and Bad Ideas in Rust Audio?


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:

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 (, 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 ?



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.


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.

Some more related crates:

  • heapless: data structures that do not need memory allocation
  • VecStorage: the crate that I wrote to allow the same memory to be used for things with different lifetimes