Enable cpal's pulseaudio feature by default

[chrisduerr]

Going to start this with a bit of a tangent, please bear with me:

The other day I updated my phone's Kernel and ran into some audio issues, where rodio's audio was playing extremely silently, ignoring output volume level, and not showing up in my audio playback sources. I figure this is probably something wrong with my setup, but a simple aplay seems to work out just fine. Long story short: I ran cpal's beep example and realized I get an error by default, but it works just fine if I enable the pipewire or pulseaudio features.

Now it doesn't really matter why the alsa path isn't working, but on Linux generally pulseaudio is the standard audio playback path. It's most likely to provide a consistent and pleasant audio playback solution. What I do right now is depend on the latest rodio and cpal git, then just specify the pulse feature to make sure it's enabled automatically for rodio too. But this took some tinkering to figure out and get working.

Pulseaudio (and to a lesser degree pipewire) is the standard audio playback system for Linux, so would it make sense to add a feature for one (or both) of these and enable it by default?

This is mostly a suggestion, you might have some opinions on this already, I figured since this required upstream work in cpal it might have just fallen off the radar.

[roderickvd]

cpal maintainer here.

Thanks for sharing your idea. The difficulty with it is, like you say is that the Linux audio system on the desktop is fragmented between PulseAudio and (increasingly) PipeWire. If we’d follow that logic, we’d want to (also) have PipeWire by default, but that won’t work when PipeWire build dependencies aren’t available on a PulseAudio-only system.

Several options, to name a few that should be provide a reasonable out of the box experience:

1. Do nothing. Keep ALSA as safe default. Accept user difficulties not understand why their default device isn’t working (it’s held by their audio server already) and perhaps falling through to dmix or other broken-by-default plugins.

2. Enable PulseAudio by default. PipeWire has a pipewire-pulse compatibility that I think is installed on most if not all distributions. Problem is that more you dive into PulseAudio, the better you understand why someone thought to create another Linux audio server from scratch called PipeWire. PulseAudio has issues with realtime safety and does not support timestamps well, to name two topics that bit me already in cpal.

3. Introduce a build script gated by some auto-host feature to check build dependencies at build-time and compile in PulseAudio and/or PipeWire as they are present on the system. I’m not so sure yet what I think of that C-like autoconf behavior.

[chrisduerr]

Thanks for sharing your idea. The difficulty with it is, like you say is that the Linux audio system on the desktop is fragmented between PulseAudio and (increasingly) PipeWire.

Just to be clear: While pipewire is more frequently deployed on systems, almost all applications still interact with it through the pulseaudio API.

If we’d follow that logic, we’d want to (also) have PipeWire by default, but that won’t work when PipeWire build dependencies aren’t available on a PulseAudio-only system.

Build dependencies is a valid point, however I'd argue that getting in user's face about this problem makes it easier to deal with it. A cargo error about missing pulse/pipewire dependencies would make it trivial to figure out how to disable those features, but audio not working properly is much harder to troubleshoot.

I think enabling just pulse is probably most likely to cause the least issues, but as someone who uses pipewire on all my systems at this point I wouldn't mind having pipewire enabled by default too. Enabling both would likely increase the risk of errors about missing pipewire dependencies, but is probably still fine?

The way I understand this, none of it would be required at runtime. So as long as it's just about pulling in additional build dependencies which can be disabled with no-default-features, I think that's an overall improvement (at least from my point of view).

[roderickvd]

Just to be clear: While pipewire is more frequently deployed on systems, almost all applications still interact with it through the pulseaudio API.

Valid point. Although if I could help migrate the ecosystem away from that, I'd be happy to contribute.

I think enabling just pulse is probably most likely to cause the least issues

For an out-of-the box experience for users who "just want playback or recording", you may be right. For DAWs, A/V sync or low latency guarantees, it's different.

The way I understand this, none of it would be required at runtime.

No, compiling with pipewire enabled will require the libraries to be available at runtime too. This may only matter for binary distribution.

at this point I wouldn't mind having pipewire enabled by default too

So because of that runtime requirement, should we go that route, it'd be pipewire by default and let it blow up for users to down-select to pulseaudio or plain ALSA. This might be an aggressive move and break the build by default on quite a number of systems.

[chrisduerr]

Valid point. Although if I could help migrate the ecosystem away from that, I'd be happy to contribute.

That's fair, though I'm not sure there's a big focus on that. Making it easy to use would be nice, but I think waiting for pipewire to be more widespread before deciding on it as a default would also be a reasonable approach.

For an out-of-the box experience for users who "just want playback or recording", you may be right. For DAWs, A/V sync or low latency guarantees, it's different.

From what I can tell, rodio is the only big player in Rust when it comes to audio playback. So I think the majority of users are likely just interested to 'play some stuff'. For the default user experience, I do think it makes sense to optimize for that. If your application has a focus on audio playback specifically, I don't think tweaking the library you use to facilitate that would come as much of a surprise/burden.

So because of that runtime requirement, should we go that route, it'd be pipewire by default and let it blow up for users to down-select to pulseaudio or plain ALSA. This might be an aggressive move and break the build by default on quite a number of systems.

That's certainly aggressive, but for Linux users I'm pretty sure this would still provide a better user experience out of the box rather than 'accidentally' using alsa. A quick upfront compilation issue is something Rust users should be familiar with, but having audio/playback issues is something that (imo) is much more likely to reflect poorly on rodio.

Does the pulseaudio feature also require runtime dependencies? You only mentioned pipewire, so it sounded like enabling pulse by default would only come with the drawbacks of using pulseaudio, which essentially is still the standard for Linux audio playback.

[roderickvd]

From what I can tell, rodio is the only big player in Rust when it comes to audio playback. So I think the majority of users are likely just interested to 'play some stuff'.

There's a few more, but more the the point we should distinguish between what cpal does by default (which is the perspective I was commenting from) and what Rodio does by default.

Does the pulseaudio feature also require runtime dependencies? You only mentioned pipewire, so it sounded like enabling pulse by default would only come with the drawbacks of using pulseaudio, which essentially is still the standard for Linux audio playback.

pulseaudio also needs the C libraries installed.

[yara-blue]

So I think the majority of users are likely just interested to 'play some stuff'. For the default user experience, I do think it makes sense to optimize for that.

I agree with the sentiment that it should be as "easy as possible" to get basic audio output working. We can provide documentation on how to get the lowest latency (that requires fiddling with buffer sizes anyway).

Horrendous crazy take: we could have a default where we require alsa, pulseaudio and pipewire, then we check for those in a build.rs and provide a very nice explanation on how to require less (turn off default features for the backends you do not want) and the exact consequences of that. At runtime we first try a Pipewire host then fallback to Pulseaudio and finally alsa as fallback.

Edit:
Even crazier, we can dlopen the required shared libraries from rust code and if they are not available move on to the next target. That cussedness should live in cpal though.

Edit2:
Honestly I'm gravitating towards the craziest idea. It is easiest to compile, most robust and gets the best behavior possible on the end user machine, finally it can be combined with <try_something()> like methods to allow the cpal user to do something when their preferred back-end is missing (warn for higher latency for example).

[roderickvd]

Horrendous crazy take: we could have a default where we require alsa, pulseaudio and pipewire, then we check for those in a build.rs and provide a very nice explanation on how to require less (turn off default features for the backends you do not want) and the exact consequences of that. At runtime we first try a Pipewire host then fallback to Pulseaudio and finally alsa as fallback.

That's what I meant with the autoconf way of doing things. If we were to do it, I feel it should live in cpal, and even then be feature-gated. Then we can discuss whether it should be opt-in or opt-out in cpal, and whether it should be opt-in or opt-out in Rodio.

Edit: Even crazier, we can dlopen the required shared libraries from rust code and if they are not available move on to the next target. That cussedness should live in cpal though.

I don't think it could live in cpal? Probably that should belong in the pipewire and pulseaudio crates. Beyond expanding the scope of work further into the ecosystem, I'm not feeling it: cpal would then depend on those crates gracefully doing going forward in the future. I know we can pin to specific versions but I don't like behavioral coupling to libraries not under control.