State of Pipewire support? And do you plan to support it at all?

[rempas]

First of all, hello and thanks for your work and dedication! I was initialing looking into GLFW (as an alternative to learn over SDL) as I heard that it's smaller and lightweight. This will be even more important to me as I'm planning to use one of the two (or anything else) to create a GUI framework for the programming language I develop. However, GLFW doesn't have support for audio so, here I am searching for audio libraries!

Now for the question itself. I searched in the threads but I haven't seen one that directly makes this question and I have seen a direct answer. But I would be really interesting to know your plans regardless supporting Pipewire as it is such a nice library that has matured and it's more and more becoming the default audio backend for most Linux distros.

[mackron]

A PipeWire-specific backend is an unfortunate situation. miniaudio has a requirement that it does not depend on any development packages for any backends (it achieves this through dynamic linking at runtime with dlopen()). This is how miniaudio has such a simple build system. Unfortunately this is not possible with PipeWire because it has a hard dependency on non-trivial inlined code in it's headers. Specifically, spa_format_audio_raw_build() is the problem. Unless PipeWire adds a wrapper API which can be dynamically linked with dlsym(), a built-in PipeWire backend will never happen unfortunately.

However, the good news is that the next big version of miniaudio (0.12) will be adding support for modular and pluggable custom backends without the need to modify miniaudio.h. I'm already part way through building a custom PipeWire backend which I'm using as a real-world test. Once that's done it'll be placed in the extras folder in this repository, but for the reasons I mentioned earlier, it'll never be integrated directly into miniaudio.h, and you'll need to install the PipeWire development packages if you were ever wanting to use it.

(Also, you're probably already aware of this, but PipeWire has a PulseAudio layer that allows it to work via the PulseAudio backend.)

[rempas]

That's great! I think that pipewire-pusleaudio is very stable! Firefox uses it and I never had any problems with it.

And no, I have no interest in...

That's really sad! One of the big problems of C, C++ is indeed their build systems and build ecosystem in general. In 2023, after so many decades, even if someone created a package manager for C and C++ like how other languages have (D has Dub, Rust has Cargo, Python has Pip etc.), it would take forever for people to upload their packages and support them. But at least making it as simple as possible is a good idea I think so good job my friend!

[rempas]

Thanks a lot for the discussion! I will close it now but if anything changes in the future, we can talk again! Have a nice day my friend and let me know if you need anything else!

[mackron]

It's a sort of cultural thing. I think a lot of people who do C and C++ development have a default view on what the build system should look like and then just assume that's just how it has to be (multiple files, lots of linking to other libraries, build system dependencies like CMake, etc.). I've had people ask me to add CMake support to miniaudio before even though you can just add miniaudio.h to your source tree directly! It's like not using a build system is a totally foreign concept to some people.

Like I said before, there have been issues before with the PipeWire-PulseAudio emulation layer with miniaudio in the past. miniaudio seems to be stable with it at the moment however, but I'd be interested to hear if you have any issues. Good luck, and enjoy!

[mackron]

Oh, and if PipeWire does indeed add a wrapper for the spa_format_audio_raw_build() that can be linked with dlsym(), and you hear about, I'd be very interested to know about that.

[rempas]

No please! Keep miniaudio small and simple! I do love seen open minded people that try to keep things simple and try to make innovations!

I will find some time to try and use miniaudio for real. I do have to create the compiler for my language first, then I can learn GLFW and Vulkan so I can create a GUI library for my language. miniaudio will be part of the team to handle the sound!

That's my plan at least. I know that things don't always go as planned but I do appreciate your time and effort. I will try miniaudio in that state and I will tell you if I have any problems (and of course, report any bugs if I find any) but for my real, productive usage and review, we'll both have to wait. Is that good enough for you?