Pipewire finally fixed previously unfixable audio delay buildup over bluetooth when the system was under load. I've been using it for over 2 years and did not experience any drawbacks.
I seem to be an exception. Although I love Pipewire for doing a lot of things right and finally solving a lot of issues that plagued Linux' multimedia stack in the past, I haven't had any major issues with PA for at least 10 years, while now that I switched to Pipewire a while ago I have occasional stuttering Bluetooth audio once again.
This is really great news. Pipewire made great progress in the last few years. It solves a lot of problems I had with Bluetooth headsets in PulseAudio.
Anecdotally, Bluetooth audio is now better for me than on my Windows (same hardware) and Mac devices. From poor quality to higher latency, Pipewire's made quality at least as good, and latency the best of the three OSes.
Seconding this. On my c.2020 high-end laptop running Win11, from switching on my BT headphones to hearing audio through them takes around 8 seconds and sometimes requires manual intervention. On my c.2013 laptop running Arch+PW, 3 seconds.
It sounds like I've missed some backstory. I gather people have issues with Pop!_OS 22.04's audio subsystem?
From my perspective, 22.04 is no better or worse than previous releases.
I've always had Bluetooth audio issues with Linux. And I'm usually outputting audio to the laptop speakers or to HDMI, which have worked just fine.
My comparison is with fedora (pipewire by default) and debian stable (pulseaudio). Bluetooth works better, e.g. switching between headset and better audio quality automatically, and you get compatibility with Jack for free.
Also sound and video recording and sharing now has a nicer standard and works better with wayland.
That said, it is a drop-in replacement, so pretty unnoticeable for most purposes. So if you notice nothing at all, that means success.
I remember when Ubuntu's boss announced moving window buttons to the left two weeks after ui freeze of upcoming lts. That was the beginning of the end of the Ubuntu's desktop for me.
I got bitten by this. It's one of the worst things to leave a taste in my mouth for a while :/.
They could have at least put out a patch release of the install CD but afaik it was still shipping with the broken version months later (which was a pity when I needed a live CD that was... safe to use... on my filesystem).
I hope some day I'll be able to make Pipewire work on Debian without messing everything else in the process: tried to install and set up it a few times and always failed ending up with no audio.
Now I have an almost perfect situation with very low latency (4 ms or less) using Reaper with Alsa alone, no Jack involved. Also, by using Yabridge I solved all compatibility problems with Windows plugins, even those which wouldn't run anymore on modern Windows versions. If you ever had problems with LinVST, Yabridge will likely eliminate them all. My only problem now is the inability to play along a track I'm listening to with Qmmp or other player (that is, outside of Reaper) as it takes entire control of the audio. I would have to use either Pulseaudio with much much higher latency or Jack with all its configuration issues.
I don't know about your specific use case but my switch to Pipewire (on Ubuntu, to be fair) was quite easy to pull off. Stop+disable/uninstall PulseAudio, install Pipewire + Wireplumber + pipewire-pulse + whatever else you need, enable the necessary services by default on login and you're mostly done.
My switch to Manjaro has only left me with one annoyance and that's that it doesn't remember the default sink for some reason. So far the 2 second clicks haven't been annoying enough for me to invest time into fixing that, but one day I'll probably find that darn broken setting...
Of course, but Ubuntu and Debian ship different versions of system libraries so one experience doesn't transfer to the other as well as you might otherwise expect.
I also plan to switch the music PC to Manjaro soon. I really like that distro, maybe not as Debian for tinkering (networking, embedded boards, etc) but for desktop use looks really great to me: I already install it whenever someone asks me to migrate to Linux their PC.
I use a old Steinberg CI1 external USB card, but those figures should be obtainable also with on board audio chipsets as they got a lot better in the last decade.
Nice, I think this is great. Say what you will about Canonical but they've got the market share and the cajones to switch up defaults like this (Wayland, PipeWire) which will ultimately help drive forward innovation and adoption.
Red Hat/Fedora were the ones to develop and push both Wayland and Pipewire, and Fedora was the first distro to make both default. Ubuntu is merely following their lead.
I tried Manjaro in a VM and was pretty disappointed by AUR. The selection is only a little ahead of Debian's official core packages. Debian 11 and derivatives really have a lot.
I also don't like how you have to compile your own AUR frontend. You would think that would be pre-included, since it seems to be one of the star attractions of Arch.
I wasn't a fan of how long it takes to compile things. I also remember having to figure out dependencies manually, it doesn't just do it all for you like apt/dpkg.
I don't fully trust it any more than random AppImages from GitHub releases, to be honest, since I've heard there has been malware in the past, and compiling yourself gives zero protection.
Unless you are going to read through tens of thousands to millions of lines of code, you're still just trusting whoever put the package up there, and hoping you would have heard about it if there was a virus. I suspect not nearly as many people go around randomly reviewing code as some might like to think.
It does work, and I can see the value if you want to use things that for whatever reason aren't in Debian.
I actually kind of like the curation effect that Debian has though. If it's in the repos, it gives you a clue about what is popular enough that someone bothered maintaining it. If it's not in Debian and Fedora, it's probably more experimental than I'd like it to be.
Arch never switched since doesn't enforce the default sound server. You can choose any unless dependencies force use to use one. The official arch installer even prompts the user to chose between pipewire and pulse on install.
Per-application volume, Bluetooth device support with automatic profile switching, headphone jack detection, and probably 5 other things I use daily but don't know about.
alsa alone works fine for me as well… a sound server would make sense to me if i did a lot of audio processing using a bunch of different applications, but how many people really do that anyway as opposed to just working in some overengineered DAW?
That makes a few assumptions: that I don't want to change it while the app is running, that I don't want to set the output to another app, that I don't want outputs into multiple sinks, and that setting environment variables for all apps is trivial.
This actually sounds like something that might make me switch to Pipewire one day.
The rest of your comment seems to indicate to me that you have some kind of professional audio setup? Or is it something that might be interesting for the rest of us, too?
Yes, but that's not related to the comment. I tried to avoid my fancy use cases. It's more that through this I know that pipewire makes some scenarios trivial that people normally wouldn't know how to achieve or would spend lots of money on (https://rogueamoeba.com/loopback/ for $100+)
The rest is just basic usage. For example, I'm in a video call and want to add just the browser's sound output to the call, but still hear it myself. With pipewire, that's "open (your preferred audio graph tool)", "drag and drop from browser to zoom". Runtime change, multiple sinks, including app sink.
Not sure, he did also pulseaudio (which is funny because I'm not a fun of either of his two most known works, systemd being the top offender for me) so he might touch something in piperwire also.
Pipewire started as "Pulseaudio, but for video"; later audio features were also added. It still uses the Pulseaudio and JACK APIs and should be a "drop-in" compatible replacement for both.
I don't think RedHat or anyone ever said that Pulseaudio is perfect or covers all use cases.
You mean lennart poettering. Also the guy behind systemd. He's a bit controversial since he goes against the Unix philosophy and isn't very nuanced in expressing his opinion, but all criticism is easy in hindsight. Pulse audio was a great improvement over what was available at the time and systemd is IMO better than any alternative it replaced.
Sometimes, less is more. Red Hat has an incentive to replace old, established, boring and well-known technology with new, exciting, unreliable and unfamiliar technology, because their income comes from support services.
Well, Canonical does, to be fair. They just seem to be unsuccessful at gaining adoption. Part of this is my suspicion that they just do it to get their IP on the map (like with the snap store that only they can manage). But I would imagine that RedHat's goals are similar, after all they are a commercial entity too.
Personally I don't really trust either and I lament the high level of commercial involvement in Linux. It's one of the reasons I use FreeBSD. And they are still doing very well in features. For example they had jails (real containers, not chroot) way before Linux had containers.
I don't believe in "win-win scenarios" when it comes to commercialisation. In the end the commercial interests will always trump everything. I think RedHat's recent actions around CentOS are a good example of that.
The standard procedure for me is uninstalling pulseaudio and installing "apulse", which is ALSA-glue for applications that depend on pulseaudio, e.g. browsers. And my experience with Bluetooth is that it works fine directly with ALSA.
The idea behind Pulseaudio was fine, but the implementation was horrible. Lennart didn't have audio programming experience, and focused heavily on the bluetooth music streaming use case. Performance-wise it was awful, particularly for games since it took control of all audio. Eventually it got much better, but it still isn't very good at low latency output.
Pipewire is a completely new backend written from the ground up keeping interactive use cases in mind. It implements the Pulseaudio API for compatibility, so it can be used as a drop-in replacement, but has its own extensible interface.
That's fantastic! I swapped out pulseaudio for pipewire on my Arch installation and it immediately fixed all of my bluetooth issues. Everything just worked.
Great news! Had some problems with my Jabra USB sound card for wireless headphones until I switched over to pipewire. Also helped latency issues in OBS studio with my USB mic.
Hard to overstate what a blessing Wim Taymans has been for dealing with AV in linux. Both gstreamer and pipewire have really moved the bar. Qualitative engineered and a joy to work with.
That news item is only saying that wireplumber will activate pipewire as an audio server, and won't allow you to use it for video only (with pulseaudio serving audio).
It's irrelevant for those who've picked pipewire as audio server specifically, so it will most likely be irrelevant for Ubuntu.
Plus the Ubuntu 22.10 release is in October 22 (they use calendar versioning), so there's still some time to work out the kinks.
Take a moment to thank leonard Potter, who despite death threats from ignorant "fanboys" and incessant mockery from people who never wrote a line of non-bash code has made immense contributions to Linux being usable on desktop. If someday Linux does end up being usable by the average Joe, Mr potter would have had a huge role to play in it. Let's trmenytgat pipewire stands on the shoulder of giants and it replaces an excellent system (which sadlt rarely happens in Linux space)
Did you ever used Pulseaudio. Some years ago sound was not working at all, the only way to make it work was to kill pulseaudiod and stick with ALSA. Now it started working and is being replaced. No comment.
Pulse was a long time ago. I think it was a bad idea to not cover low latency, but it's not Lennart's fault if distros shipped it too soon. It works fine now, and was a lot nicer than raw ALSA at the time. But Pipewire is definitely an upgrade.
Does it handle ASIO for multitrack audio recording and playback? Would it let me plug multiple Black Magic Design video I/O cards into a linux machine and use them simultaneously? Does it do AES50, MADI, AVB, Soundgrid, and Dante?
80 comments
[ 3.2 ms ] story [ 145 ms ] threadAFAIK this version of Pop!_OS is using pipewire, so I wonder if there's still more work to be done?
From my perspective, 22.04 is no better or worse than previous releases. I've always had Bluetooth audio issues with Linux. And I'm usually outputting audio to the laptop speakers or to HDMI, which have worked just fine.
That said, it is a drop-in replacement, so pretty unnoticeable for most purposes. So if you notice nothing at all, that means success.
If you knowingly corrupt data, then what else matters?
(Having "we recommend that people who use ZFS don't upgrade" hidden in release notes doesn't negate it)
My switch to Manjaro has only left me with one annoyance and that's that it doesn't remember the default sink for some reason. So far the 2 second clicks haven't been annoying enough for me to invest time into fixing that, but one day I'll probably find that darn broken setting...
I also don't like how you have to compile your own AUR frontend. You would think that would be pre-included, since it seems to be one of the star attractions of Arch.
I wasn't a fan of how long it takes to compile things. I also remember having to figure out dependencies manually, it doesn't just do it all for you like apt/dpkg.
I don't fully trust it any more than random AppImages from GitHub releases, to be honest, since I've heard there has been malware in the past, and compiling yourself gives zero protection.
Unless you are going to read through tens of thousands to millions of lines of code, you're still just trusting whoever put the package up there, and hoping you would have heard about it if there was a virus. I suspect not nearly as many people go around randomly reviewing code as some might like to think.
It does work, and I can see the value if you want to use things that for whatever reason aren't in Debian.
I actually kind of like the curation effect that Debian has though. If it's in the repos, it gives you a clue about what is popular enough that someone bothered maintaining it. If it's not in Debian and Fedora, it's probably more experimental than I'd like it to be.
Why would I want per-app volume? Pretty sure all relevant apps have a setting for that.
> headphone jack detection
What do you mean by this? My headphone jack works just fine with just ALSA and no configuration.
> probably 5 other things I use daily but don't know about
Doubt.
This actually sounds like something that might make me switch to Pipewire one day.
The rest of your comment seems to indicate to me that you have some kind of professional audio setup? Or is it something that might be interesting for the rest of us, too?
Yes, but that's not related to the comment. I tried to avoid my fancy use cases. It's more that through this I know that pipewire makes some scenarios trivial that people normally wouldn't know how to achieve or would spend lots of money on (https://rogueamoeba.com/loopback/ for $100+)
The rest is just basic usage. For example, I'm in a video call and want to add just the browser's sound output to the call, but still hear it myself. With pipewire, that's "open (your preferred audio graph tool)", "drag and drop from browser to zoom". Runtime change, multiple sinks, including app sink.
Did they realize they needed a better solution? (though Pipewire also deals with video)
(the point here is basically: why couldn't they fix pulseaudio?)
* low latency / pro audio
* secure video streaming and desktop capture under Wayland
* unification of Jack and PulseAudio ecosystems (Pipewire implements both APIs)
Probably.
But the Pipewire developer is at Red Hat, and Fedora has it as default.
I don't think RedHat or anyone ever said that Pulseaudio is perfect or covers all use cases.
Personally I think the Linux world follows redhat way too closely. Especially since it's really IBM now.
But I'm more open to pipewire because of this. Having nice people behind it is important too IMO.
Personally I don't really trust either and I lament the high level of commercial involvement in Linux. It's one of the reasons I use FreeBSD. And they are still doing very well in features. For example they had jails (real containers, not chroot) way before Linux had containers.
I don't believe in "win-win scenarios" when it comes to commercialisation. In the end the commercial interests will always trump everything. I think RedHat's recent actions around CentOS are a good example of that.
I'm pretty sure he got similar amounts of criticism at the time
Pipewire is a completely new backend written from the ground up keeping interactive use cases in mind. It implements the Pulseaudio API for compatibility, so it can be used as a drop-in replacement, but has its own extensible interface.
Because that worked out so well for Mir and Upstart, right?
https://lwn.net/Articles/847412/
https://www.collabora.com/news-and-blog/blog/2022/03/08/pipe...
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ
I'll put that in my fortune file.
Arch tried to switch off from `pipewire-media-session`, because it's merely a proof of concept whose development is dead, but found that WirePlumber simply isn't ready yet (https://archlinux.org/news/undone-replacement-of-pipewire-me...).
It seems like, unless and until WirePlumber is actually ready, PipeWire isn't quite ready?
It's irrelevant for those who've picked pipewire as audio server specifically, so it will most likely be irrelevant for Ubuntu.
Plus the Ubuntu 22.10 release is in October 22 (they use calendar versioning), so there's still some time to work out the kinks.