SerenityOS
Lagom without pulseaudio on linux? (question)
Hi, I'm very new to this project, so forgive me if I'm missing something. Is it possible to use lagom and libaudio without Pulseaudio on linux systems? I do not have pulseaudio on my linux box, and installing it wrecks everything (i make music, so this is critical). Is there a way to use a different library for audio, or directly use Alsa instead of going through Pulseaudio?
(By the way, since Pulseaudio uses alsa, I question why the decision was made to use pulse instead alsa - the cited reason of lower latency can be even further improved by bypassing Pulse entirely, and it also increases compatibility (at least with a wider base of Linux-based systems) compared to forcing going through Pulse.)
Have a look to the HAVE_PULSEAUDIO option if you want to see more details on where it's used.
But I think the main point is summerized here:
https://github.com/SerenityOS/serenity/blob/1f62984301256bfab5eb99508b7a1ce8aab2df6f/Userland/Libraries/LibAudio/PlaybackStream.cpp#L25-L35
For Linux we only support PulseAudio, but you should be able to build and live without it (and without audio). However, it should be fairly easy to add a plugin to support another backend, but I guess that we might want to go with Pipewire though.
Ladybird also supports audio through Qt, if that's the app you're trying to use. It will use Qt if PulseAudio is not installed, and if the right Qt6 package is installed (e.g. qt6-multimedia-dev on Debian, see https://github.com/SerenityOS/serenity/blob/master/Documentation/BuildInstructionsLadybird.md). That's only available for Ladybird though, because it's a Qt app on Linux - other Lagom apps don't have a Qt audio backend currently.
Even if pulseaudio was available at build-time? Or is pulse detected at build time?
I have pulse headers and libraries on here for debian reasons, but not the process itself.
I was pretty sure i had qt6-multimedia-dev... It was for ladybird, so that's good to know at least.
It looks for the headers at build time. See Meta/Lagom/CMakeLists.txt:
CHECK_INCLUDE_FILE(pulse/pulseaudio.h HAVE_PULSEAUDIO)
As you can see on the extract I put above, HAVE_PULSEAUDIO is a build-time variable.
And its value is based on the presence of the header:
CHECK_INCLUDE_FILE(pulse/pulseaudio.h HAVE_PULSEAUDIO)
Forcing the value to OFF should make it use Qt, as PulseAudio is prefered otherwise.
I have pulse headers and libraries on here for debian reasons, but not the process itself.
The libraries and headers are all you need. We don't run any external binary for audio, we just link the library. Is that not working for you?
We could probably use PipeWire libraries, or dip into ALSA if needed. But from my understanding/point of view PulseAudio was chosen because it's still the default on common distros that our developers are using. iirc Ubuntu 22.04 still ships it, they didn't switch to PipeWire until 22.10. The audio support on Linux and for Ladybird in particular is currently at a level of "play audio at all in a way that doesn't sound choppy" rather than focused on "play audio with low latency, low cpu usage, low memory usage, ...". If there's a more portable, more efficient, way to use other libraries than PulseAudio as a backend for our LibAudio implementation that you know how to do, I'm sure @Zaggy1024 would love to take a look at your approach and compare it to the PulseAudio one :)
If there's a more portable, more efficient, way to use other libraries than PulseAudio as a backend for our LibAudio implementation that you know how to do, I'm sure @Zaggy1024 would love to take a look at your approach and compare it to the PulseAudio one :)
Indeed, to abstract it up to the level of the interface we use for audio in Ladybird, I would think we'd need to create a lot of the functionality that's also needed for Serenity to properly time audio playback, so ALSA support wouldn't hurt.
The reasons I chose PulseAudio as the backend were:
- It's widely supported. (debatable? I don't know, I'm not really in touch with Linux audio)
- PipeWire supports the PulseAudio APIs, adding onto the above point.
- It already provides interpolated and accurate timing for the current audio timestamp to allow syncing time timeline or video to the audio. Without this, it would've taken quite a lot of effort to implement and test audio time interpolation.
- Not sure how true this is, but my understanding was that PulseAudio builds a customizable mixer on top of ALSA, so supporting ALSA instead of PulseAudio would mean that the user experience could suffer.
- I had a reference in https://github.com/mozilla/cubeb which made it easier to get started.
- PulseAudio came built into the distro I was building on.
Those reasons made a pretty compelling argument to make me want to use it, rather than delving deep into the ALSA APIs for a few weeks and figuring out how to get audio to come out of my speakers.
That said, it definitely can't hurt to have an alternative. The only downside would be if its functionality isn't maintained and breaks eventually, but we may be able to get some decent testing by using some of the same classes between ALSA and Serenity if there is enough overlap.
(By the way, since Pulseaudio uses alsa, I question why the decision was made to use pulse instead alsa - the cited reason of lower latency can be even further improved by bypassing Pulse entirely, and it also increases compatibility (at least with a wider base of Linux-based systems) compared to forcing going through Pulse.)
The latency issue was mostly caused by some very sub-par API usage by Qt which I wasn't able to find a way to bypass without writing my own abstraction layer instead. Lower latency is always better as long as it doesn't introduce stuttering, but latency at the moment is low enough (even through WSL2) that I'm not concerned about it, at least for Ladybird's use case.