Live data from Hacker News

C++ audio mixing library design

lisyarus.github.io

21–30 of 54 posts

Re: C++ audio mixing library design

#21

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

C23 says hello.

C is becoming into everything C++ has, minus OOP and the additional type safety.

Re: C++ audio mixing library design

#22
post #21

Earlier quoted context omitted.

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…

C23 says hello. C is becoming into everything C++ has, minus OOP and the additional type safety.

Examples? Because the list of accepted proposals seems conservative. https://en.wikipedia.org/wiki/C2x https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu

Re: C++ audio mixing library design

#23

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

One does the same approach as Rust, wrap the unsafe C stuff into type safe C++ wrappers.

Which the author did quite alright, minus the issue I discussed on separate comment.

You will have better luck moving the audio industry from bad C practices into modern C++, than making most learn a complete new language.

JUCE rules in the audio industry for example.

Re: C++ audio mixing library design

#24
post #21

Earlier quoted context omitted.

C23 says hello. C is becoming into everything C++ has, minus OOP and the additional type safety.

Examples? Because the list of accepted proposals seems conservative. https://en.wikipedia.org/wiki/C2x https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu

You have to look forward to what in the plate post C23 like lambdas, improved constexpr, more _Generic support, and so forth.

https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...

Re: C++ audio mixing library design

#25

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…

Freedom from overflow, and noise floor stays level-dependent. Meaning that when you multiply your float signal by a certain volume the quantization noise is at most -140 dB RMS. If it were integer, the quantization noise would depend upon how loud your (signal x gain) is. Besides, top-level compressor/reverbs use double :)

Re: C++ audio mixing library design

#26
post #24

Earlier quoted context omitted.

Examples? Because the list of accepted proposals seems conservative. https://en.wikipedia.org/wiki/C2x https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu

You have to look forward to what in the plate post C23 like lambdas, improved constexpr, more _Generic support, and so forth. https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...

Lambdas and some other complicated looking extensions have been on the plate for quite some time, and it seems like none of them made it into C23. Lambdas in particular have been promoted for the most part by a single person AFAICT. "C is becoming into everything C++ has" is a drastic misrepresentation.

Re: C++ audio mixing library design

#27
post #23

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

One does the same approach as Rust, wrap the unsafe C stuff into type safe C++ wrappers. Which the author did quite alright, minus the issue I discussed on separate comment. You will have better luck moving the audio industry from bad C practices into modern C++, than making most learn a complete new language. JUCE rules in the audio industry for example.

This argument can apply to every application scene of Rust: no need to learn a new language. Yet the fact is that the Rust community is growing rapidly, from audio to embedded devices. I think the key is how much you can get from the investment, and I totally understand if people want to stick to the ecosystem they are already familiar with, a completely different story compared with a beginner.

Also, I don't think the JUCE "rules in the audio industry". First, the most typical use case for JUCE is to write VST plugins. Second, the company ROLI was trying to develop another language called SOUL. Although its progress seems to stop now, it somehow shows that they are trying to provide something different from C++.

Re: C++ audio mixing library design

#28
post #15
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`.

std::span is new, but I have seen some custom form of it in pretty much every codebase I've worked with for a very long time (and implemented some myself). Like it used be the case for std::string in older codebases.

Re: C++ audio mixing library design

#29

    - A stream is something you can play as a sound. It may be loaded from a file or generated on the fly. It may be finite or infinite. One important thing is that a stream is single-shot: it doesn’t have a restart method or anything like that.
    - A channel is something where a stream is actually played. You can request the channel to stop, or you can replace the stream this channel is playing.
Am I mistaken, or isn't this very close to what GStreamer already does with sinks and sources?

Re: C++ audio mixing library design

#30
post #21

Earlier quoted context omitted.

C23 says hello. C is becoming into everything C++ has, minus OOP and the additional type safety.

Examples? Because the list of accepted proposals seems conservative. https://en.wikipedia.org/wiki/C2x https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu

It is conservative, except for nullptr which duplicates NULL. This violates C's own charter of "provide only one way to do an operation."
Post reply on HN