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.
Weâll see when it lands on 21.10 đ¤ˇ
Will Ubuntu move to PipeWire in 21.10?
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.
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.
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:
- 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.
- 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.
- 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.
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.
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.
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?
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
Can you clarify? I have Bluetooth working with my Neon with Pipewire.
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.
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.
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.