Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ audio mixing library design

lisyarus.github.io

Post reply on HN
Print view View original

11–20 of 54 posts

Re: C++ audio mixing library design

#11

Post by lisyarus »

pjmlp wrote: post #2

Very nice article, however in 2022, why using C arrays as parameters in C++ code, when std::span, std::vector exist?

std::vector would definitely be the wrong choice, since I typically want to pass random subsections of random arrays to be filled by audio samples. std::span would be a good choice, though (I actually have my own span in the engine, from before C++20). Why didn't I use it? No idea, just didn't come to my mind. Guess it might be the influence of the book I was reading, or of SDL_Mixer interface, etc. I may do some refactoring in the future and use spans instead.

Re: C++ audio mixing library design

#12

Post by Narew »

chaosprint wrote: post #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…

Doesn't you will have the same issue, a C-like interface. Maybe I missed something, but Rust and ffi mean you use a C interface from C++ ? The only C++Rust I know is either using C intermediate code or using cxx.rs but the support is limited ?

Re: C++ audio mixing library design

#13

Post by stodor89 »

> 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).

I started as a C++ programmer (back when C++0x and boost were all the rage), but the more time passes, the more of a C admirer I seem to become.

Re: C++ audio mixing library design

#14

Post by chaosprint »

Narew wrote: post #12
chaosprint wrote: post #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…

Doesn't you will have the same issue, a C-like interface. Maybe I missed something, but Rust and ffi mean you use a C interface from C++ ? The only C++ Rust I know is either using C intermediate code or using cxx.rs but the support is limited ?

Yes. But we can do it in the last step, right?

    #[no_mangle]
    pub extern "C" fn process(
        in_ptr: *mut f32,
        out_ptr: *mut f32,
        size: usize,
        result_ptr: \*mut u8
    ) {
        let _in_buf: &mut [f32] = unsafe { std::slice::from_raw_parts_mut(in_ptr, size) };
    }

Re: C++ audio mixing library design

#15

Post by planede »

pjmlp wrote: post #2

Very nice article, however in 2022, why using C arrays as parameters in C++ code, when std::span, std::vector exist?

std::span is new enough to not be in muscle memory of C++ programmers.

Even the standard library commits a similar sin with `from_chars` and not taking a `string_view`.

Re: C++ audio mixing library design

#16

Post by PennRobotics »

lisyarus wrote: post #10
urban_winter wrote: post #3

I 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…

The smallest nitpick: The accepted variable for frequency is f or nu (ν). The formula and units are correct in the article, but lowercase omega is understood as angular frequency and would take the place of 2πf. I also got 3 hours of sleep, so I could be wrong.

Also, thanks for the great article and a possible alternative to my own SDL_mixer woes!

Re: C++ audio mixing library design

#17

Post by pjmlp »

lisyarus wrote: post #11
pjmlp wrote: post #2

Very nice article, however in 2022, why using C arrays as parameters in C++ code, when std::span, std::vector exist?

std::vector would definitely be the wrong choice, since I typically want to pass random subsections of random arrays to be filled by audio samples. std::span would be a good choice, though (I actually have my own span in the engine, from before C++20). Why didn't I use it? No idea, just didn't come to my mind. Guess it might be the influence of the book I was reading, or of SDL_Mixer interface, etc. I may do some ref…

Thanks for the feeback.

I only raised the issue, because this is how new programmers keep doing mistakes in C++ when learning the code from others, specially projects that they find are cool to learn from.

As you seem to use best practices in the rest of the code that seemed strange to me.

Re: C++ audio mixing library design

#18

Post by lisyarus »

PennRobotics wrote: post #16
lisyarus wrote: post #10

Earlier quoted context omitted.

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…

The smallest nitpick: The accepted variable for frequency is f or nu (ν). The formula and units are correct in the article, but lowercase omega is understood as angular frequency and would take the place of 2πf. I also got 3 hours of sleep, so I could be wrong. Also, thanks for the great article and a possible alternative to my own SDL_mixer woes!

Indeed, thanks!

Re: C++ audio mixing library design

#19

Post by stoeckley »

stodor89 wrote: post #13

> 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). I started as a C++ programmer (back when C++0x and boost were all the rage), but the more time passes, the more of a C admirer I seem to become.

Same. I've written probably more C++ than any other language, and I have a lot of respect for the language overall, but I recently had to use only C for something, and I found it rather refreshing. My use case didn't hit a lot of the pain points of C, but it did feel refreshing as there are fewer ways of doing things, fewer options, compared to C++, and my code ended up feeling more straightforward and readable as a result.

Re: C++ audio mixing library design

#20

Post by KayEss »

urban_winter wrote: post #3

I 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…

One big reason is that when you add two samples together, if you overflow a signed int that's UB, but if you go over 1.0 on a float it's just business as usual. This means you can do a ton of audio processing and only have to deal with fixing the overflows in one place right at the end (they use a compressor, but other algorithms are also possible).
Post reply on HN