Anyone here doing any lower-level audio programming in Rust?
I’ve been interested in trying to build/prototype my own eurorack modules using micro-controllers, yet am wary of diving into C/C++. I’ve used Rust before and it’s much more to my liking… Was curious if there are people out there using it for this sort of stuff. It seems to have good micro-controller / embedded systems support.
Yes, I’ve been doing quite a lot of Rust on Bela, and also, a sizeable portion of Firefox’s audio code (100% of the low latency audio IO code on Linux, for example, soon also on OSX) is written in Rust. Another team at Mozilla (I do audio work there) is reimplementing the whole Web Audio API in Rust, that works well. It’s indeed very well suited for this kind of work.
All that is on top of a either a real-time kernel or a normal general purpose kernel, but Rust works well, for example, without an allocator, and, as you note, there are lots of resources for embedded development, including support for stm32f, that people like to use in eurorack.
It’s quite refreshing to use Rust compared to C or C++ as you say, I heartily recommend it for any work where very high performance and/or real-time is a requirement. It’s takes bit longer to learn than C or C++ (at least that’s my experience), but this is very easily paid back by the fact that most bugs that are not logic bug are caught at compile time. Also I find the final code much more robust than what I usually do in C++. Usually, when it compiles, it works.
The compiler is very helpful in pointing out possible solution to problems, and the community is very welcoming. The package manager is a game changer compared to C or C++, all the very nice data structures and algorithms are just a package away, and there are thousands of packages, implementing cutting edge lock-free data structures, various DSP bits, bindings to tons of libraries and system APIs, etc.
Update: I’ve spent the last couple of months working on a Rust library for constructing modular synthesizers called Oscen
It’s still in its early stages, but is already quite fun and powerful! It lets you construct DSP chains using prebuilt/custom synth modules that can be re-patched dynamically and controlled with midi.
I’m hoping to build a VST that utilizes this library soon.
Learning the theory or learning about what rust offers?
For rust, you can start by using Crossbeam and searching on crate.io (https://crates.io/search?q=lock-free), that yields quite a lot of interesting things, but one would have to make sure data structures are real-time safe. Using those in your rust program is as simple as adding the version to the manifest (called Cargo.toml), and that’s it.
For the former, https://www.youtube.com/watch?v=Q0vrQFyAdWI and https://www.youtube.com/watch?v=PoZAo2Vikbo are nice, and about real-time audio, specifically. In general the material from this conference is very good for people that want to broaden their perspective in terms of audio programming. I’ve personally learnt with " The Art of Multiprocessor Programming" by Nir Shavit & Maurice Herlihy. A lot more theoretical, but provides a solid foundation, if that’s necessary, for example to implement data structures (vs. using them). The Crossbeam project mentioned above also has a long list of resources to learn about all this, https://github.com/crossbeam-rs/rfcs/wiki. I recognize quite a few items from this list and can vouch for its relevance for audio programming (and it applies to various language, not only rust).
Thanks, seems quite a bit of interesting activity around rust for real-time programming and related topics in public domain… Started poring through some links you sent, there was quite a bit there!
Coming from a web dev background looking to go a little lower level, would you see any problems with starting off with Rust? I have some experience with Java, but otherwise my knowledge generally starts and end with Javascript through the whole stack and I’d like to branch out a bit. A friend of mine seems really into Rust but just not sure whether I’d rather dive in with C++ first. Somewhat off topic, I realize
No problem with starting with Rust, although a reading proficiency in C and/or C++ is often useful when doing low-level work, if only to interface with other code or to read other implementations.
Searching around, there seem to be quite a few well-maintained resources for people that come from a JavaScript background. I wouldn’t know what to recommend, because my background is the exact opposite: I’ve been working with systems programming language the most in my professional and personal life, and use web technologies only occasionally, and never for production stuff.
I’ve just posted this to the Octatrack thread but I think it might be relevant here as well.
Today I released a new ot_utils rust library for making it easy to concat audio samples and generate .ot slice files for the Octatrack.
I’ve also updated AudioHit (my Rust based CLI for auto trimming and fading audio samples) to add ot_utils functionality (so it can batch process a sample folder and create a unified .wav and .ot file using the generated files).
I’ve been off and on working on an arm usb midi library in pure Rust for a few folks up here in Vancouver and I have to say thus far the dsp Rust landscape is pretty sparse right now. I see a ton of Rust dsp work being done right wrapped around C libs so if you’re willing to accept the impurity of the C-underpinnings in your Rust project, now is the time to start hacking! Side note, I just dusted off a thought-lost Aleph last week and absolutely had the port-to-rust urge almost immediately. Once I have more bandwidth in Sept, I’d love to start a rust working group for blackfin or avr32 with some interested peeps!
another Aleph owner here, I’m not very good a rust, only done some tutorials, but I like it so far and porting some Aleph code sounds like a great way to learn more.
It’s not black or white. The critique is valid, there are some counterarguments too, and people may still find value in Rust (as they do in C++, and I won’t turn this into a vs. thread either). But I think that people need to be aware that Rust is not a panacea (no programming language is) and that it does tend to encourage a lot of the same bad habits and reaching-for-complexity problem solving, instead of using the right (often the simplest) tool for the job and fully comprehending the problem space. Concurrency is not always the answer, knowing when the simplicity of a lock is appropriate versus the complexity of lock-less, or wait-free architectures (which come at their own cost), or knowing how to architect to avoid the need for the lock in the first place (which is what a lot of good audio programming comes down to in some places).
As long as the programmer is aware and makes the choice consciously, then I say use whatever is best for them (could even be Java or JS for all I care), but it’s important not to get so enthusiastic about a language or features that the downsides, costs, and encouragement to avoid good programming discipline are forgotten.
The ‘C’ we were writing for blackfin is pretty weird btw… In order to get the best out of this guy you have to make extensive use of the ‘fractional arithmetic primitives’ built into blackfin GCC (I believe they map pretty directly to blackfin hardware instructions)
I wanted to get round to playing with blackfin assembly directly but didn’t…
Blackfin is another can of worms, yeah. It’s a funky beast. There’s a reason a lot of the embedded DSP world is moving towards ARM, cycle (in)efficiency notwithstanding. But that veers offtopic.
To try and keep on-topic I guess the point I was trying to make is that aleph might not be a good platform to experiment with rust for dsp.
Unless of course you have the chops & time to customise the language to support blackfin fractional types in a nice, more integrated way than bfin gcc… Can’t imagine why you would go that route tbh!
Does rust allow dynamic recompilation of parts of a running rust program? For example recompile just one function by invoking rust’s compiler from within the program and hotswap the new function definition with the old. If it supports this stuff can it also support the dynamic recompilation on a bare metal embedded platform?
I was messing with these kind of techniques for an audio application in C using .so shared objects and also trying to get these tricks playing nice with Jack threads. The whole thing was messy and my implementation probably has bugs but seems quite workable.
I shelved it and started half-heartedly learning llvm to see if there’s a better way, got distracted by another thing, etc…