C++ audio mixing library design
lisyarus.github.io
C++ audio mixing library design
1–10 of 54 posts
Re: C++ audio mixing library design
#2Very nice article, however in 2022, why using C arrays as parameters in C++ code, when std::span, std::vector exist?
Re: C++ audio mixing library design
#3I wonder if, in retrospect, the decision to use floats was a good one. The author mentioned issues with the time of each sample for the sine wave, which were float-related. I get that audio effects (compresser, reverb etc) are probably easier using floats but I don't immediately see why it's better to have float as the core data structure and convert to int at the end rather than having int as the core and convert to/from float only when needed.
Re: C++ audio mixing library design
#4Very nice article, however in 2022, why using C arrays as parameters in C++ code, when std::span, std::vector exist?
SDL takes array pointers as arguments for its audio output functions in general, so I would assume they were coding against the SDL Audio API.
Re: C++ audio mixing library design
#5Very nice article, however in 2022, why using C arrays as parameters in C++ code, when std::span, std::vector exist?
SDL takes array pointers as arguments for its audio output functions in general, so I would assume they were coding against the SDL Audio API.
No reason to use them on C++ method definitions.
void engine::callback(std::span output)
{
std::size_t samples = 0;
if (stream_)
{
samples = stream_->read(output.data(), output.size());
if (samples == 0) stream_ = nullptr;
}
auto remaining = output.subspan(samples);
std::fill(remaining.begin(), remaining.end(), 0.f);
}Re: C++ audio mixing library design
#6"All my engine is in C++, and I’m really sick of SDL_DoThatThing(&options, pointer_to_void, size_in_magical_units, &callback, user_data, legacy_value) (sorry for all C admirers, I do respect you, it’s just that I’m not one of you)."
How about Rust audio (https://github.com/RustAudio) and then FFI?
I am developing the audio lib for the music live coding language I design in Rust and I think the experience of Rust is really good, because of `cargo` (the package management), the community, the syntax and compiler, the ergonomics, and so on. For one of my usages, the audio lib in Rust compiles to wasm and runs in browsers smoothly. I can also write VST plugins with the same audio library in Rust:
https://github.com/chaosprint/glicol
There are also many other Rust audio libs such as dasp, fundsp and hexosynth, all worth checking out. Before I became addicted to Rust audio, I had checked some C++ audio project, such as the Maximillian lib especially the JS bindings, the source code of SuperCollider and the JUCE for VST. But apparently I have made my decision for the reasons abovementioned.
Re: C++ audio mixing library design
#7I love audio programming, it's one of those things that's provided me with a lot of joy. I've been working on our in-house audio library for our game engine as well, and designing custom effects for it. In our case, we wanted an 80s DSP sound, so it was fun diving into the old literature. In the end, a simple design won out: https://twitter.com/JasperRLZ/status/1567546255454371842
Re: C++ audio mixing library design
#8I wonder if, in retrospect, the decision to use floats was a good one. The author mentioned issues with the time of each sample for the sine wave, which were float-related. I get that audio effects (compresser, reverb etc) are probably easier using floats but I don't immediately see why it's better to have float as the core data structure and convert to int at the end rather than having int as the core and convert to…
Yes it's a good decision, and 'the standard' for audio in the same way as 32-bit ARGB makes everything easier for graphics.
Of course there are some things that are better done with ints or maybe doubles, like keeping track of the time position, but for the sine wave generator it doesn't need to know how long it's been running in total, just the position in the current cycle, so floats are fine for that.
Re: C++ audio mixing library design
#9"All my engine is in C++, and I’m really sick of SDL_DoThatThing(&options, pointer_to_void, size_in_magical_units, &callback, user_data, legacy_value) (sorry for all C admirers, I do respect you, it’s just that I’m not one of you)." How about Rust audio ( https://github.com/RustAudio ) and then FFI? I am developing the audio lib for the music live coding language I design in Rust and I think the experience of Rust is…
Adding a whole new language (meaning compiler, packaging, libs, ecosystem) into my engine just for the audio lib which I _wanted_ to implement myself in the first place? No, thanks.
Re: C++ audio mixing library design
#10I wonder if, in retrospect, the decision to use floats was a good one. The author mentioned issues with the time of each sample for the sine wave, which were float-related. I get that audio effects (compresser, reverb etc) are probably easier using floats but I don't immediately see why it's better to have float as the core data structure and convert to int at the end rather than having int as the core and convert to…
The alternative that my older code used was int16, and it has way bigger precision issues (32-bit float has 23 bits of precision, and in16 has 15). Fundamentally audio samples are just numbers; the fact that they have to be in the [-1..1] range in the end is a hardware technical limitation (the speakers' membranes can only vibrate so much), but there's nothing in the audio itself that says it should be constrained to some range. So, floating-points are a nice fit. Fixed-point math like 16.16 might be a good alternative, but floats have hardware support, so here we go.