A curated chat archive of the various Rust Audio chat rooms
Rules:
- Follow the rules of the source chat room(s)
- Only document publicly available information
- Do not explicitly quote anyone without their permission
Guidelines:
- Only post Q&A and technical discussions (if someone answers their own question, that's fine too): Things like project updates, organizational drama, and other news don't really make sense to document on this wiki.
- Avoid opinions: "I think JACK is all you need to support" should instead be "JACK is cross-platform, so an application that uses it as a backend could hypothetically run on most modern computers"
- Change/add a timestamp if you edit a section: it's nice to know how out-of-date a piece of information could be. Use
, which will turn into a datestamp when the edit is published.~~~~~ - If someone mentions details regarding their project, try to omit them unless the information is important, '''and''' they give permission
FAQ
What are some resources for learning DSP?
https://github.com/BillyDM/Awesome-Audio-DSP
Why should I use Rust over C++?
(paraphrased from this comment)
- DSP: About the same, since it's just performing calculations, the performance of which is roughly the same across almost all compiled languages.
- Metaprogramming: C++ templates are a little more flexible than Rust macros, and Rust's generics require a lot of explicitness since they're more closely tied to the type system.
- Plumbing: Thread and type safety are really nice to have, and eliminate whole classes of bugs. Something something "fearless concurrency".
- Abstraction level: Rust's memory model is simpler, and doesn't really give up much in terms of higher-level abstractions. You can easily and ergonomically use Rust for anything from a bare-metal embedded program (as long as you're on ARM or RISC-V) to a browser application (via WASM) to a web server, and anything in between.
(a couple additions that were not in the above comment)
- Cargo is lovely
- Refactoring is really nice
- Async is fun, though not particularly useful for audio applications yet
- A lot of nice development tooling:
- integrated unit tests,
- benchmarking
- docstrings
- helpful error messages
- the
log
crate - panic traces
- error handling in general
- nih-plug is really nice
How do I create virtual audio devices that I can route signals to/from?
At time of writing (2023-06-15) there aren't any robust cross-platform methods for this, but on Linux, using Pipewire or JACK as your audio server will let you route audio freely. Pipewire works with both PulseAudio and JACK clients, while a JACK server will only be able to communicate with JACK clients.
linkdump
- https://github.com/RustAudio/dasp for some DSP building blocks
- https://github.com/MeadowlarkDAW/creek for audio streaming from disk
- https://github.com/wrl/baseplug/blob/trunk/examples/svf/svf_simper.rs svf code example
- https://github.com/WeirdConstructor/HexoDSP
- https://github.com/WeirdConstructor/synfx-dsp
- https://github.com/tesselode/kira Library for expressive game audio
Realtime programming:
Graph processing:
- https://fgiesen.wordpress.com/2018/03/05/a-whirlwind-introduction-to-dataflow-graphs/
- https://github.com/m-hilgendorf/audio-graph
Crates for handling soundfonts:
- https://docs.rs/soundfont/latest/soundfont/ only parses
.sf*
files, and doesn't actually do any audio decoding - https://docs.rs/fluidlite/latest/fluidlite/
Discussion
Issues with WAV file decoding
Pitch/frequency of the resulting output is too high
- Check to verify that the sample rate of your file matches the sample rate of the output
- Make sure that the channel count is being taken into consideration. If you are reading a mono WAV file as if it were stereo, the resulting output will be an octave higher (double the frequency) and twice as fast (half as long)
Output amplitude is too small/large
- Make sure the numeric type is correct (i.e. not an f32 when you should be using an i16)
Trig function ranges
Traditionally, sine functions will have a period of 2π, but (allegedly) in many implementations of sine, the input is scaled to make the range from 0.0 to 1.0. If possible, it would make more sense to just make your initial phase range from 0.0 to 1.0 and use a sine function that doesn't do the rescaling to save two multiplications. The performance benefit of this is pretty minimal.