Pipewire is a true blessing for Linux
Official Release Page for those who don’t want to read the Phoronix article: https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.0.0
It’s great to see that Pipewire has reached this milestone. Personally I’ve been using it since 0.3.35 for very basic audio needs and it’s been a very smooth transition. After installation I never had to tinker with it anymore. "It just works"TM
I had to do some tinkering way back to make my bluetooth earplugs be recognized as an audio device.
Not sure if that is still needed today
No
deleted by creator
Genuinely one of the best pieces of software that these heroes are giving away.
I’ve seen so many audio changes on Linux. But Pipewire is the first one without any negatives.
Yeah it’s basically Pulseaudio, but better. The devs have done a great job on iterating upon the already pretty good pulseaudio!
It’s more like JACK for desktop. PA was never good, just obvious bad design.
I’d have to disagree with that. It wasn’t perfect and there were issues for many people at the beginning, but it united everything properly.
Before then (in xmms days), don’t forget that audio in apps constantly didn’t work, and the sound servers often conflicted. It was far from a seamless experience.
But, pipewire I agree doesn’t seem to have any downsides and finally fixes from what I felt was the last major issue (low latency)
PA works on most case tho. Can’t deny all the good it did.
Also, is JACK any good?
Pipewire replaces the need for jack, which was low latency audio routing between audio components. Pipewire even has jack compatible interfaces so you can use jack based apps with it.
Then there’s the bit most people skip over. Pipewire does the same thing for video!
Didn’t work on my last two sound cards, and always had latency problems for many people.
JACK is for profesionals. If you need to take an input from an instrument, run it through a software filter, and output it immediately. Or if you need to output from one program to another to another. Etc. Usually that means small buffers and a lot of cpu usage. Not really for normal desktop users. Grab a specialized distro like ubuntu studio and try it, if you want.
Pipewire makes me feel like I’m a bit stupid. I keep reading about it, I read the introduction and FAQ on their website, yet I still couldn’t tell you what that thing even does. All I know is it’s a slightly less buggy drop-in replacement for pulseaudio, and pulseaudio is something I use because Firefox forces me to. (I would still be on plain old ALSA if it weren’t for Firefox.)
Also, it definitely did not “just work” for me out of the box, I had to do quite some digging and some very non-obvious stuff to get it to a) start up and b) let me use my microphone. I still don’t even know what “starting up” really means for pipewire (is there a daemon or something?), the website likes to pretend that isn’t a thing, but without doing some stuff to start it up, audio just won’t work for pulseaudio and pipewire applications…
The Arch wiki made installing it very painless for me. Zero problems. Install it, remove PA, activate systemd service.
you can install pipewire directly from archinstall now
I hope the garuda linux devs found it as easy as you. Wish they would disable the 5 second standby timer by default, but I’ll manage.
btw
For a long time, people shat all over pipewire and said it wasn’t viable as a replacement for the existing Linux audio stack, but clearly that hasn’t ended up being the case
I’ve heard nothing but good, and replacing Pulseaudio was painless. It was Pulseaudio that people hated on in my experience
When it was brand new there were some edge case bugs that broke on certain workflows and hardware, but that’s pretty much entirely fixed now and I’m guessing for a long time now it’s been more universally stable than pulseaudio was.
Also, some people just pointlessly dislike anything that’s new, or because it breaks their spacebar heating
Hol up, 1.0? I’ve been using it and thought it was around for few years already
Is there something like the banana voicemeeter for pipewire?
I am currently using Helvum, which is kinda lacking a lot of the functionality.
I was experimenting with the Cadence tools from KXStudio. These are mostly made for JACK, but PipeWire has a JACK interface so it should work. It’s similar to helvum, but with more options.
Not sure right now which one (maybe Carla), but one of these programs also support adding sound effect nodes that have their own GUI! You probably want to use it in multi-client or patchbay modeSadly cadence seems to be dead: https://github.com/falkTX/Cadence
Oh, that’s sad news. These are really great tools :(
My audio set up is using jack on Ubuntu. If I were to start using pipewire, does it replace jack? Or do you use it alongside jack? I use mostly ardour, hydrogen, renoise and bitwig.
Pipewire exposes both a JACK and Pulseaudio client interface, so you don’t need to run the JACK daemon anymore.
Nice! So it completely replaces jackd/qjackctl? Can it sync transports?
qjackctl will actually connect to pipewire, I use its graph window a lot to route audio when the default volume control isn’t enough. But yeah it does (or can) replace jackd.
Can it sync transports?
I’m not sure, I’m not a pro audio user. Sorry!
Cool, thanks for the info!
big fan of qpwgraph
I believe a problem you may encounter asking this question is the fact pipewire does most of that itself?
This is the best summary I could come up with:
It has finally happened: PipeWire 1.0 has been released as this now very common software to the Linux desktop for managing audio and video streams.
With time it’s proven to be a suitable replacement to the likes of PulseAudio and JACK while pushing forward the Linux desktop with its modern design and feature set.
PipeWire 1.0 delivers improved time reporting for less jitter in ALSA when using IRQ mode, various module fixes, Bluetooth LC3 codec and compatibility improvements, improved transport and time handling for JACK, optimized buffer re-use with JACK, and a variety of other improvements.
There isn’t anything fundamentally different about PipeWire 1.0 but was part of their plan for releasing 1.0 later in the year and finally moving past all the 0.3.xx releases.
PipeWire has proven itself stable and plenty reliable for Linux desktop uses.
Downloads and more details on the big PipeWire 1.0 release via FreeDesktop.org GitLab.
The original article contains 161 words, the summary contains 150 words. Saved 7%. I’m a bot and I’m open source!
lets go
Brilliant piece of software
Oh nice! I wonder if this will fix discord streaming audio?
Nope. This will only be fixed when Discord gets their head out of their ass, unlikely to happen soon.
Can you describe the issue? I don’t use Discord (and I presume the problem might depend on what browser you use).
on discord on linux you can’t screenshare with desktop audio, I think this might be already fixed in newer electron versions (but discord is closed source and has not updated their electron in a long time)
That absolutely sucks :| Thankyou for the detail.
As a workaround, you could use OBS and use OBS’s virtual camera so Discord is streaming what it thinks is a camera, and set up whatever you want to share on your desktop through OBS.
I have discord installed from the flatpak. Screen sharing works but it doesn’t share audio from the applications. Discord-screenaudio and web browser discord have been suggested to me but they don’t work with unfocused push to talk. I’ve also tried xwaylandvideobridge but that didn’t stream the audio either.
I’m assuming this is a “dedicated app” (i.e. apt install discord). I was capable of streaming the video, but sound was a different beast. Audio streaming on discord was a no go. I was finally able to do it with pipewire and using discord-screenaudio
https://github.com/maltejur/discord-screenaudio
A custom discord client that supports streaming with audio on Linux
Jaysus, I wish this were a world where stuff like that wasn’t necessary.
Uneducated question: what’s the benefit of a dedicated client over running it in a normal browser?
Sorry for late reply. I just now noticed this.
The difference would be that a browser would likely have multiple web pages fighting for resources whereas the dedicated client would not have to fight over so many resources.
The OS has a dedicated task scheduler that alots cpu time to each process. Some processes get preferential treatment, but most processes started on user space ( i.e.double click UI icon) are just “normal” priority.
When a task scheduler hits on a process, that process can start executing whatever it needs to do. The problem with running discord in a browser is that the application is splitting its attention across multiple pages ( and probably other stuff ) instead of a single page.
Basically, it’s faster to focus on painting a single canvas than it is to painting 3 at the same time.
I’m not going to discuss shared memory and separate processes or forking. You can goggle search if you want to know more about that.
I am not so sure that it will end up faster or better.
**In theory: **A CPU scheduler should give programs as much CPU time as they want until you start nearing CPU resource saturation. Discord doesn’t need very large amounts of CPU (admittedly it’s a lot more than it should for a text chap app, but it’s still not diabolically bad). It will only start getting starved when you are highly utilising all cores. That can happen on my 2-core laptop, but I don’t have any games on my 6 core desktop that will eat everything. Nonetheless on my laptop I’d probably prefer my games take the resources (not Discord) and I’d happily suffer any reasonable drop in responsiveness of Discord as a result.
I don’t think that a new process (a new dedicated browser-client) instead of a new thread (tab in existing browser) is intrinsically faster or better. CPU schedulers are varied and complex, I wouldn’t be surprised if any differences in performance measurements would end up down in the noise. If anything the extra memory usage might cause more IO contention and memory starvation, making everything slower rather than faster. But this is all conjecture, so don’t give it much credit.
Basically, it’s faster to focus on painting a single canvas than it is to painting 3 at the same time.
I don’t think that’s much of a problem in practice, at least for Firefox: one tab can crash and stop rendering completely (or lock up 100% of 1 CPU core) but the others will keep going in other threads. For the most part they shouldn’t be able to affect each other’s performance.
In practice: What’s the actual metric that you think will be better or worse? I assume responsiveness to typing and clicks in the discord UI?
I’ve never seen discord lag or stutter from causes other than IO limitations (startup speed, network traffic, heavy IO on my machine) or silly design (having to refresh the page after leaving it open all day, I suspect it’s intentionally auto-disabling but I’m not sure). That’s not something that running a separate discord client in a separate dedicated/embedded browser will fix.
Discord doesn’t support steaming desktop audio when screen sharing on Linux. They do on other platforms and there’s no technical reason why they do t support it, they just don’t seem to care all that much.
I’ve hacked around this using Pipewire. I used qJackCtl to route the audio output of my game into Discord’s audio input. Suboptimal, because people will hear my audio regardless of whether they joined the video stream or not, but not it worked for the scenarios I needed it to work for.
Discord will need to fix their code on Linux if they want to support this stuff out of the box. Pipewire supports streaming application audio just fine, but that doesn’t matter if Discord doesn’t implement it.
Kind of the same deal with Zoom and video sharing on Linux: they decided to use the wrong API (screenshot API) so there’s no way for the rest of the platform to fix their limitations.
I’ve been using PipeWire this year on my Void Linux laptop & desktop. It’s been mostly OK but has a few problems. For years I have been using plain ALSA (with no custom configuration) because pulseaudio causes me regular issues across multiple machines (mostly silently failing).
Pros:
- I don’t have to use Chromium for my mic to work on online video conf (WTF Firefox)
- “EasyEffects” lets me quickly fix crappy youtube audio (bad gain normalisation, way too much sibilance) with a minimum of effort.
Cons:
- Sometimes breaks all audio until I manually restart it (hey, just like pulseaudio. This problem never happens when using ALSA straight)
- First time setup is complicated, involving environment variables, dbus user session buses and multiple daemons (running just pipewire isn’t enough). Why can’t it handle this all itself? Surely it should notice if these things are missing and just fix it itself? Compare this to straight ALSA where you (1) do nothing and then (2) everything works (except Firefox mic support)
- I can’t have multiple audio outputs all unmuted at the same time. Eg my headphone output and my rear speaker output. If I override this (using alsamixer) then it gets forgotten next boot anyway, it seems to be out of scope of PipeWire’s understanding.
I can’t say I share your experience. There were a few packages I needed to install (pipewire, pipewire-pulse, and wireplumber) but after an apt install I was pretty much good to go, were it not for the fact Pulseaudio was already running and enabled so not all of Pipewire autostarted by default.
Had to enable it of course (systemctl --user --enable) because it inherently conflicts with Pulse, but on systems that now ship with Pipewire by default, that’s all done for you. Only config I ever messed with was forcefully enabling mSBC and SBC-XQ to get higher audio bitrates over Bluetooth.
I think the packaging on the more “hardcore” distros is intentionally dynamic because some people may prefer to keep Pulseaudio, but enable Pipewire for video capture on Wayland. Not many applications make use of it, but Pipewire can so route video streams. Installing both pipewire-pulse and Pulseaudio will lead to a race condition on which audio subsystem is used if both are enabled by default.
I’m not sure what limitations you have with your use of different outputs. It’s possible that pipewire-pulse doesn’t expose all data for Pulse software to properly route audio to multiple devices, but Pipewire itself can do it. I’ve used qJackCtl (and pw-jack) to send audio channels through different filters and then to different output devices, the underlying system is very capable.
I know my Gnome setup likes to undo all manual audio routing when I plug in an audio device, but I’m too lazy to look into how I would fix that. It may be related to some PulseAudio wrappers? Worth noting that I had the same problem on Pulseaudio, which makes me suspect it’s a Gnome thing.
- Sometimes breaks all audio until I manually restart it (hey, just like pulseaudio. This problem never happens when using ALSA straight)
Well, how much lennart is in this thing? Not only can that predict how well it’s going to work, but also how soon it’ll be fixed, how responsive the ‘team’ will be to bug reports, how compatible it’ll be with other system components AND whether ‘compatibility’ will be achieved before the entire OS has been systematically imported into (and badly replicated by) the project.
I don’t think honestly he gets enough credit.
If you check SystemD, its a HUGE step up, which is why everyone is using it now (whereas, the old scripts had race conditions, were a pain to write and other issues). Anyone who has written both can tell you how much better things are now…
The fact this issue is happening on both Pipewire and Pulseaudio also suggests it’s more likely a bug in the drivers… It might not be obvious on ALSA directly, but that doesn’t mean an issue doesn’t exist there…
And honestly, the situation before PulseAudio was awful. Audio not working was a common issue, and low latency audio was the least of anyone’s problems. Whereas, these days, because of Pulseaudio, even gaming is a thing now (back then, I even saw issues on tuxracer, and Unreal tournament back in the days).
In regards to setup, most distributions will handle that anyway I’m guessing. So not sure why the configuration process should matter unless you’re in Arch or Slackware? As long as the distribution handles it, it shouldn’t matter. It’d really a non-issue honestly.
I do a lot of middleware development and we’re regularly blamed by users for bugs/problems upstream too (which is why we’ve now added a huge amount of enduser diagnostics/metrics in our products which has made it more obvious the issues aren’t related to us). In practice, very few people have issues with Pulseaudio (I haven’t seen issues since launch). Sometimes as well, keep in mind it can be the sound interface (especially if its USB)
The fact this issue is happening on both Pipewire and Pulseaudio also suggests it’s more likely a bug in the drivers… It might not be obvious on ALSA directly, but that doesn’t mean an issue doesn’t exist there…
I probably made the overlap unclear, sorry:
- Pipewire issues: My 2023 desktop and 2016 laptop, very different hardware.
- Pulseaudio issues: All of my pre-2023 desktops and several family laptops
I do a lot of middleware development and we’re regularly blamed by users for bugs/problems upstream too (which is why we’ve now added a huge amount of enduser diagnostics/metrics in our products which has made it more obvious the issues aren’t related to us).
Eep, that’s annoying. You also probably don’t have direct interaction with the users most of the time (they’re not your customer) which makes this worse, people in a vacuum follow each other’s stories.
In practice, very few people have issues with Pulseaudio (I haven’t seen issues since launch). Sometimes as well, keep in mind it can be the sound interface (especially if its USB)
There might be a bias here because these problems are not persistent, ie a reboot fixes them.
In regards to setup, most distributions will handle that anyway I’m guessing. So not sure why the configuration process should matter unless you’re in Arch or Slackware? As long as the distribution handles it, it shouldn’t matter. It’d really a non-issue honestly.
That’s potentially more things different distros can do differently and more issues your middleware will start getting blamed for.
Yes it’s not a problem for user-friendly distros, but why does the user friendliness problem exist anywhere anyway? It’s better to fix problems upstream, not downstream.
If you check SystemD, its a HUGE step up, which is why everyone is using it now
I think that’s a “winners write history” situation. There were other options at the time that might have been better choices. Everyone uses it now because of Redhat and Debian being upstream to most users, desktop and corporate. I was not surprised by Redhat adopting it (it’s their own product) but Debian was quite the shock.
Yes systemd is definitely a step up from traditional initscripts (oh god). In terms of simplicity, reliability and ease of configuration however it’s a step below other options (like runit). I don’t have distro management experience but, given the problems I’ve encountered with different init systems over the years, I suspect there would be less of a maintenance burden with the other options.
I’m very curious about the downvotes to this one. May I ask people’s thoughts? Perhaps I’m too vague? I can put a bigger story about my experiences with various init systems in production & research if people are interested.
