Pipewire on Ubuntu

I tried just last week to swap pulseaudio for pipewire. It kind of worked for on-board and USB audio devices reasonably well, but I could not make bluetooth audio work at all (yes, I did have the correct packages installed) - audio interfaces would fail to connect / pair.

Maybe fixed in version 0.3.26?

  • Many Bluetooth improvements, support for hardware volumes.
    Bluetooth

  • Various memory leaks and crashes are fixed.

  • Added support for AVRCP hardware volume.

  • Added support for HSP/HFP hardware volume.

2 Likes

We’ll see when it lands on 21.10 🤷

Will Ubuntu move to PipeWire in 21.10?

7 Likes

I think Ubuntu should consider moving to Pipewire and replacing PulseAudio with Pipewire. Steam’s Beta version now requires Pipewire to run. If that’s the direction Valve is going to take, not moving to Pipewire will affect Steam users who’re on Ubuntu.

3 Likes

Web browsers also use PipeWire because it’s the defacto interface for screen sharing in Wayland sessions. But that’s unrelated to potentially using it as an audio daemon.

6 Likes

Well, here’s the thing. If we’re going to already install it (and it’s not just web browsers, btw, OBS also needs pipewire for screen capture in Wayland) we might as well go all out and let it handle pulseaudio and jack traffic as well.
We have the following use cases:

  1. User currently uses a mix of Jack and Pulseaudio software (ie Rosegarden and Hydrogen alongside vlc and whatever else). Jack is known to take access to the audio hardware away from Pulseaudio when it’s active. With Pipewire, Pulseaudio programs can continue to produce sound even if the Jack programs are running. Because Pipewire will handle both Pulse’s and Jack’s duties and manage, mixing it itself.
  2. There will be programs that natively uses pipewire for audio in the future. These programs will cause Pulseaudio’s own daemon and Pipewire’s daemon to fight over available audio hardware. It gets uglier when Jack gets added into the mix. The logical workaround in this scenario is let Pipewire handle Pulseaudio and Jack as well.
  3. Lastly, it just makes more sense to have just pipewire running and handling all three different protocols than having three daemons with similar functions but different protocols running concurrently and fight over the one available audio hardware.
1 Like

One point you are missing out there is that most users don’t install jack nor have such sophisticated requirements, they just want audio to work and be reliable in simple situations (watch videos, play music, make calls through skype/hangout/…).

We are in a known situation today which is working well enough to cover those cases and there is no compelling reason to switch now (from your arguments, 1- is a specialized setup, people who go install jack could as well install pipewire sound server if they wish, 2- is there any such software in the Ubuntu archive yet? 3- is basically back to the first point, there is no conflict on a default installation)

We will eventually want to switch but at this point pulseaudio has been around for longer and is better tested, pipewire is still new and needs to stabilize (reading comments online from fedora users quite some people have latency issues or sound artifacts and are switching back to pulseaudio to workaround those problems). It’s not the sort of change we want to do in a LTS cycle.

5 Likes

EasyEffects natively uses PipeWire today. EasyEffects succeeds PulseEffects which is in maintenance mode. While EasyEffects is not packaged in Ubuntu today, it will likely be sooner or later.

3 Likes

At first this sounds reasonable, but life isn’t that simple. What you’re suggesting is similar to “okay, Ubuntu uses systemd, systemd has networkctl, let’s throw Network Manager away and replace it with networkctl to manage all connections”. Well, it’s doable but not necessary at all, and also could bring more issues and user frustrations along the way. A thorough testing is needed first. Here’s just my experience with Pipewire as a replacement for PulseAudio: up to v. 0.3.30 I had been experiencing troubles with auto-detection of 3.5 jack connection/disconnection. Some people still have a similar issue even with recent Pipewire builds.

On the other hand, Pipewire has fixed some Bluetooth audio issues I had with PulseAudio before. And its development pace is very impressive, to say the least. That’s why I think Ubuntu should’ve joined the party and enabled it by default in 21.10 in order to find and fix every bug that would have appeared by 2022. Why not?

6 Likes

From this user’s perspective (fairly typical Ubuntu user, not developer), Audio in Linux is a mess and this creates an opportunity for Ubuntu to add value to the stack.

I ran across this discussion while struggling how to understand / resolve my libvirt/qemu audio emulation problem (Looking Glass passthru-GPU support doesn’t and will never support spice audio).

As I said: what a mess. Apparently QEMU runs as a different user, has various esoteric settings for things like AppArmor, etc and I need to figure out somehow to get a pulse audio server running as that user (?) and route audio to my user id? This on top of all the ALSA/PulseAudio/JACK layers of complexity - it gets hugely confusing as obsolete & other distros are involved and probably often leads to screwed up machine configurations as us mere mortal users like me tinker with their systems in an effort to get basic things like audio support in virtual machines working.

At this point I’m mulling, “Hey, if I’m going to fix this, I should future-proof it a little.” I.e. switch to PipeWire. But at this point this seems to mean installing yet another ppa, drifting further from the typical supported configuration, probably causing problems at some point in the future. As someone who doesn’t mind tinkering but has to prioritize getting things done, I’m trying to keep the hacks to a minimum but it’s difficult because that always seems to conflict with the need for functionality that’s not provided by Ubuntu out of the box. And these hacks always seem to end badly, with support being withdrawn, breaking, conflicting with other hacks, etc.

For Linux and especially Ubuntu to become a mature operating system, more of these things become turnkey, meaning tinkering / hacking is minimized in order to get functionality that works for the mainstream user. Audio that ‘just works’ is a mainstream need.

From what I understand (very little), since it appears to be the latest, presumably most supportable and probably the long-term solution to Linux audio support, I’d suggest Ubuntu prioritize getting PipeWire installed into the stack ASAP with PulseAudio, etc configured to run on top of that if/when needed, but with the intention of depreciating alsa/pulse/jack/etc in the near future to simplify the system for those who just want a simple, functional system with minimal hacking & time-waste.

I hope this semi-relevant post is viewed constructively and helps resolve what I see as a sore point that needs to be deftly handled in order to get Linux & Ubuntu to a better place.

I’ve tried to enable PipeWire from Ubuntu repos instead of using the pipewire-upstream PPA and it turned out not that bad. And it solved all my issues with Bluetooth headsets without any drawback so far. I wish there was an options to switch PA/PW as we have with X/Wayland desktop sessions. It’s a shame that 22.04 will be without working Bluetooth audio out of the box. Also there is no wireplumber.

Here is my Gist on how to Enable PipeWire on Ubuntu 21.10

5 Likes

Can you clarify? I have Bluetooth working with my Neon with Pipewire.

1 Like

Not all headsets work out of the box with PulseAudio. AirPods Gen 1 can’t even connect without fighting with configs. Then there is microphone. My Xiaomi headset can’t enable it without editing configs. And not all headsets will work even after editing. With PipeWire I can even choose desired codec in the sound menu.

1 Like

Did you try to report a pulseaudio issue for the headsets not working? It sounds like a bug that should be fixed.

Also could we please stop sidetracking that topic to describe anecdotal cases of ‘$specific_hardware works better with $sound_server’.

Any software has bugs, we have reports of configurations that are buggy with pulseaudio and others with pipewire, issues should be reported to launchpad, those specific examples are not a factor in the default service discussion.

Two frustrated off-topic posts removed.

Everybody hold hands and repeat after me: “We are all friends here.”

Everybody here is patient with each other, and respects the other point of view.

7 Likes

Is there a relatively current and safe How-to if you want to test Pipewire (Audio) on Ubuntu 21.10 (or 22.04)? Or should any semi-recent Debian How-To work?

That’s why I think Ubuntu should’ve joined the party and enabled it by default in 21.10 in order to find and fix every bug that would have appeared by 2022. Why not?

I would imagine because it’d be crazy to do that just before an LTS, with Xmas and holidays in between and just no time at all to polish it up.

Pipewire as audio daemon works well for some configurations but compatibility and maturity just ain’t there yet.

For instance, anecdotically, my experience on my individual hardware is that I can’t connect bluetooth audio devices and audio jack detection is temperamental. Some pulseaudio apps won’t play any sound via the compat route.

2 Likes