Linux and audio have never entirely gotten along well together, when PulseAudio came along it actually solved a lot of problems but it's PipeWire that's the real future.
Truthfully, I was hesitent to switch my own PC over from PulseAudio to PipeWire for fear of breakage, especially with the Steam Deck — I needed things to continue working smoothly. However, I also sometimes tend to just "YOLO" for the fun of it and so I did. I'm now running PipeWire and I have to tell you how happy I am with it.
PipeWire is a project that aims to greatly improve handling of audio and video under Linux. It provides a low-latency, graph based processing engine on top of audio and video devices that can be used to support the use cases currently handled by both pulseaudio and JACK. PipeWire was designed with a powerful security model that makes interacting with audio and video devices from containerized applications easy, with supporting Flatpak applications being the primary goal. Alongside Wayland and Flatpak we expect PipeWire to provide a core building block for the future of Linux application development.
Not only is it powerful, it's also surprisingly easy to use and assorted applications have sprung up around it to support it. Software like Helvum and qpwgraph have absolutely blown my mind on how ridiculously simple they make messing with audio inputs and outputs.
Something I've wanted to do for a long time, but Pulse didn't really help and I didn't like the complexity of JACK was to get different inputs and outputs going for OBS Studio for my livestreams. Things like only having very specific audio go to certain places. Now, it's ridiculously easy.
With the aforementioned applications, you just drag wires between things and…done. That's it. How is Linux audio now this easy?!
For example, grabbing the audio from my shiny Capture Card that's attached between the Steam Deck and my PC, with a drag of a wire I can now have it going to OBS Studio and also have it so only that goes to my Wireless headset. How about music playing that only I can hear? It's a small thing but PipeWire makes everything like that simple. Duplicating and moving audio streams with the drag of a wire. I like simplicity, it makes me happy. There's a huge amount this enables without diving into confusing configuration files, and there's no terminal needed - it's all in the UI. Lovely.
Linux audio is really going places with this. If you also haven't tried PipeWire yet, you're missing out.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
AussieEevee 1 Mar 2022
Honestly, I am not a fan of when people say something is "the future". Especially in the Linux space, where choice is key.No one is taking choice away, I really don't get why you would even remotely think that. Use whatever you want.
Personally, I will keep using Xorg and Pulseaudio.
That's what calling it the future means. It means that "This will be the standard going forward".
0 Likes
had never heard about pipewire, thanks for this I'm going to try it.
EDIT: was unbelievably simple to switch on Arch; there's an Arch wiki page for it (ofc). I seem to have the same bug as Liam in Helvum, where some outputs are obscured in the graph
EDIT2: nevermind I switched back to PA. PW giving me popping noises when starting/stopping audio, despite both the hardware parameters set to disable powersaving and disabling the pipewire suspend modules in their config... maybe I'll try PW with my next computer.
Last edited by anewson on 2 Mar 2022 at 1:03 am UTC
EDIT: was unbelievably simple to switch on Arch; there's an Arch wiki page for it (ofc). I seem to have the same bug as Liam in Helvum, where some outputs are obscured in the graph
EDIT2: nevermind I switched back to PA. PW giving me popping noises when starting/stopping audio, despite both the hardware parameters set to disable powersaving and disabling the pipewire suspend modules in their config... maybe I'll try PW with my next computer.
Last edited by anewson on 2 Mar 2022 at 1:03 am UTC
2 Likes, Who?
Honestly, I am not a fan of when people say something is "the future". Especially in the Linux space, where choice is key.No one is taking choice away, I really don't get why you would even remotely think that. Use whatever you want.
Personally, I will keep using Xorg and Pulseaudio.
That's what calling it the future means. It means that "This will be the standard going forward".
you realize both Xorg and PA were "the future" at some point right
2 Likes, Who?
Honestly, I am not a fan of when people say something is "the future". Especially in the Linux space, where choice is key.While I'm fine with you using whatever, and I myself am unlikely to make a conscious choice to change but rather will just end up using whatever my distro defaults to, I think for a lot of this kind of infrastructure it's a good thing if choice is fairly . . . muted. Like I'm fine if people are experimenting with alternatives around the edges, but I'd prefer if there is a main thing that can be taken for granted that does the infrastructure task. I don't want there to be five different Wayland equivalents in competition or whatever.
Personally, I will keep using Xorg and Pulseaudio.
Last edited by Purple Library Guy on 1 Mar 2022 at 6:33 am UTC
5 Likes, Who?
For anyone using multichannel 5.1 or 7.1 HDMI audio like I do, Pipewire is useless. Multi-channel surround audio is awesome, and much nicer than using headphones.
I have a 7.1 surround system that's driven by an audio receiver. Pipewire fails to deliver multi-channel audio through Proton games (I believe native should work), and given that most Linux games are being run through Proton this is a deal-breaker.
The gitlab issue is here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/876
EDIT: It appears a solution may have been found at the end of the thread.
Last edited by drmoth on 1 Mar 2022 at 6:52 am UTC
I have a 7.1 surround system that's driven by an audio receiver. Pipewire fails to deliver multi-channel audio through Proton games (I believe native should work), and given that most Linux games are being run through Proton this is a deal-breaker.
The gitlab issue is here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/876
EDIT: It appears a solution may have been found at the end of the thread.
Last edited by drmoth on 1 Mar 2022 at 6:52 am UTC
1 Likes, Who?
That looks amazing, hopefully en a few decades when this makes it into mainline Mint you can even route individual browser tabs as well.
Between music, softphone and the various online meeting all running in the browser I could really do with being able to split it to different outputs so customers don't have to wait for me to switch default output from the speakers to the headset every time I receive a call
Between music, softphone and the various online meeting all running in the browser I could really do with being able to split it to different outputs so customers don't have to wait for me to switch default output from the speakers to the headset every time I receive a call
1 Likes, Who?
I've been on Pipewire for about a
year now, and aside from the known big with surround sound in wine it's been smooth sailing.
year now, and aside from the known big with surround sound in wine it's been smooth sailing.
1 Likes, Who?
I rely on streaming the audio from my second PC to my main PC. Still not sure pipewire can currently do that transparently.
0 Likes
It's impressive, but if you do any kind of audio work, it's not quite there yet, especially for real-time audio. But if you're doing that, you're using jack, anyway.
I'm using pipewire in music production as a dropin replacement for Jack, and can use pretty much the same buffer settings on pipewire. But then again JackD never provided the ultra-low latency that I see others claim.
There's some minor issues, but it's SO great to not have to fiddle with two parallel systems (pulse and jack) that I can live with those as development progress.
Last edited by Beamboom on 2 Mar 2022 at 1:22 pm UTC
3 Likes, Who?
I've never used PA and never needed it but I do use Jack for music production. When jack2 and jack2-dbus moved to 1.9.20 I was having problems requiring I go back to 1.9.19, so I thought now's the (first) time to try Pipewire!
While it was simple to install and worked really well (I was surprised how easy a transition it was), unfortunately I was getting constant 100% DSP load in Mixbus (based on Ardour). I fiddled with the conf files but to no avail. So I'm back on Jack (fixed at 1.9.19).
I have no doubt Pipewire will get there though and I'll be switching at some point.
While it was simple to install and worked really well (I was surprised how easy a transition it was), unfortunately I was getting constant 100% DSP load in Mixbus (based on Ardour). I fiddled with the conf files but to no avail. So I'm back on Jack (fixed at 1.9.19).
I have no doubt Pipewire will get there though and I'll be switching at some point.
1 Likes, Who?
Recently I changed PA with PW, and after 4~5 hours of trying to fix the annoying stuttering issue (Intel Sunrise Point-LP HD Audio), I decided to back to PA.
Not going to try it again that fast.
Maybe it's the future, but most likely not with my sound card.
Not going to try it again that fast.
Maybe it's the future, but most likely not with my sound card.
2 Likes, Who?
furaxhornyx 1 Mar 2022
For anyone using multichannel 5.1 or 7.1 HDMI audio like I do, Pipewire is useless. Multi-channel surround audio is awesome, and much nicer than using headphones.
I have a 7.1 surround system that's driven by an audio receiver. Pipewire fails to deliver multi-channel audio through Proton games (I believe native should work), and given that most Linux games are being run through Proton this is a deal-breaker.
The gitlab issue is here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/876
EDIT: It appears a solution may have been found at the end of the thread.
I had the opposite issue, my 6-ins/6-outs soundcard being considered as 5.1 with Pulseaudio, and having all audio in being merge into input 1, and all audio out being merged into outputs 1/2.
Switching to Pipewire fixed the issues with inputs output being mixed, without even having to resort to make unnecessary cabling with Cadence/Catia
0 Likes
slaapliedje 1 Mar 2022
Ha, so in my time with Linux we've had many audio bits.
1) OSS
2) ALSA
3) Pulse
4) Pipewire.
Granted this is ignoring a few of them here and there that never caught on beyond some audio workstation stuff, and Jack itself seems to work with the four above.
But Audio definitely has improved over the many years! Pulse was pushed out before it was stable, which is why I always hate to recommend Fedora. But others are at fault for that too, and it gave Pulse a terrible reputation. It seemed to work mostly for me though. Hopefully Pipewire is mature enough now to not have that same issue.
1) OSS
2) ALSA
3) Pulse
4) Pipewire.
Granted this is ignoring a few of them here and there that never caught on beyond some audio workstation stuff, and Jack itself seems to work with the four above.
But Audio definitely has improved over the many years! Pulse was pushed out before it was stable, which is why I always hate to recommend Fedora. But others are at fault for that too, and it gave Pulse a terrible reputation. It seemed to work mostly for me though. Hopefully Pipewire is mature enough now to not have that same issue.
2 Likes, Who?
Ha, so in my time with Linux we've had many audio bits.Yeah, I was going to write something similar. Long gone are the days when I had to compile my own kernels just to get OSS working with my Soundblaster clone. ALSA made that possible (and for all I know, isn't that still what drives audio in kernel space today?).
1) OSS
2) ALSA
3) Pulse
4) Pipewire.
Anyway, the major gripe I have with Pulse Audio is how esoteric or badly documented some of its features are. Hooking up my Yamaha A-U670 as an external sound card via USB required some fairly involved tweaking with little advice to go by. Even now that it works, I needed to get a Gnome plugin to easily switch between PC speakers and the external DAC, because unlike plugging in headphones it never does it automatically.
Not quite sure if the task will be less daunting with Pipewire, but I'm looking forward to trying it out when it becomes the new default on Ubuntu.
Last edited by kaiman on 1 Mar 2022 at 6:18 pm UTC
1 Likes, Who?
slaapliedje 1 Mar 2022
Yeah, OSS4(assuming I remember right) was the first one to actually be open source and available to be included in the kernel, but it was too late by then as ALSA had already taken over. And you are correct, ALSA is still the kernel level thing, though I want to say at least KDE and Gnome have dependency on Pulse/Pipewire so in most distributions, you can't run just raw ALSA anymore. At least that I've seen.Ha, so in my time with Linux we've had many audio bits.Yeah, I was going to write something similar. Long gone are the days when I had to compile my own kernels just to get OSS working with my Soundblaster clone. ALSA made that possible (and for all I know, isn't that still what drives audio in kernel space today?).
1) OSS
2) ALSA
3) Pulse
4) Pipewire.
Anyway, the major gripe I have with Pulse Audio is how esoteric or badly documented some of its features are. Hooking up my Yamaha CD-NT670D as an external sound card via USB required some fairly involved tweaking with little advice to go by. Even now that it works, I needed to get a Gnome plugin to easily switch between PC speakers and the external DAC, because unlike plugging in headphones it never does it automatically.
Not quite sure if the task will be less daunting with Pipewire, but I'm looking forward to trying it out when it becomes the new default on Ubuntu.
0 Likes
Beware Liam, that some Unity games use "/usr/bin/pulseaudio --check" to check for pulse support and that binary is not provided by pipewire.
Workaround is to use steam soldier runtimes or link /usr/bin/true to /usr/bin/pulseaudio or setting a different path for binaries... whatever you prefer.
Last edited by kokoko3k on 1 Mar 2022 at 7:12 pm UTC
Workaround is to use steam soldier runtimes or link /usr/bin/true to /usr/bin/pulseaudio or setting a different path for binaries... whatever you prefer.
Last edited by kokoko3k on 1 Mar 2022 at 7:12 pm UTC
3 Likes, Who?
Ha, so in my time with Linux we've had many audio bits.
1) OSS
2) ALSA
3) Pulse
4) Pipewire.
Granted this is ignoring a few of them here and there that never caught on beyond some audio workstation stuff, and Jack itself seems to work with the four above.
But Audio definitely has improved over the many years! Pulse was pushed out before it was stable, which is why I always hate to recommend Fedora. But others are at fault for that too, and it gave Pulse a terrible reputation. It seemed to work mostly for me though. Hopefully Pipewire is mature enough now to not have that same issue.
One of the reasons why PipeWire was created is to unify consumer audio (high latency) and pro audio (low latency) in a common ecosystem (ala macOS' CoreAudio), CoreAudio has great concept and I'm glad PipeWire brought that concept to Linux (and eventually will provide long-sought stability in Linux audio ecosystem)
2 Likes, Who?
Philadelphus 2 Mar 2022
One of the reasons why PipeWire was created is to unify consumer audio (high latency) and pro audio (low latency) in a common ecosystem (ala macOS' CoreAudio), CoreAudio has great concept and I'm glad PipeWire brought that concept to Linux (and eventually will provide long-sought stability in Linux audio ecosystem)This is probably a stupid question, but…why is there a split in the first place? Why can't consumer audio be low latency too? Or is this massive overkill like providing the average office worker with a monitor with a 500 Hz refresh rate?
0 Likes
slaapliedje 2 Mar 2022
Yeah... but you could already set up JackD with PulseAudio. I mostly feel it is more like Pipewire was developed just to change the name away from the bad rep that PulseAudio has...Ha, so in my time with Linux we've had many audio bits.
1) OSS
2) ALSA
3) Pulse
4) Pipewire.
Granted this is ignoring a few of them here and there that never caught on beyond some audio workstation stuff, and Jack itself seems to work with the four above.
But Audio definitely has improved over the many years! Pulse was pushed out before it was stable, which is why I always hate to recommend Fedora. But others are at fault for that too, and it gave Pulse a terrible reputation. It seemed to work mostly for me though. Hopefully Pipewire is mature enough now to not have that same issue.
One of the reasons why PipeWire was created is to unify consumer audio (high latency) and pro audio (low latency) in a common ecosystem (ala macOS' CoreAudio), CoreAudio has great concept and I'm glad PipeWire brought that concept to Linux (and eventually will provide long-sought stability in Linux audio ecosystem)
Wouldn't be the first time. Look at the mess that is Gnome. Gnome developers went all out and changed the whole paradigm of their desktop with Gnome Shell. The outcry forked two Gnome 2 clones. Then they added Gnome Classic. So really there were 3... if things made mire sense in developer land, at some point Mate and Cinnamon should combine efforts within Gnome and make Gnome Classic the best they can. But the forks still remain, and they all maintain their different ideas and code. But this for sure can be a good/bad thing as well. Now there seem to be a lot of splinter 'we can do one too!' With things like Budgie, Elementary, etc. This I think is due to people more than the tech. Would be wonderful if everyone could work together, but I sort of feel that the two coins would be either we would have the best desktop experience ever... but in 2050 after years of bickering. Or we just end up with a bunch of 'almost perfect' versions in the next 5. 😜
0 Likes
One ring to rule them all
You don't want nor need that, the monitor example is vaild if the compositor needs to render the same image 500 times per second.
Pro audio often needs extremely low latency (maybe even high bit depths and samplerates) that taxes the cpu, because to achieve it, you need to continuously load very small chunks of audio data to the audio card and that thread needs to run with realtime privileges or you'll end with what is called XRUN (empty buffer == audio glitches).
For example if you need to hear a sound sampled as soon as possible, say with a latency of 5ms, if i'm doing the math right, you need to load at most 1000ms/5ms = 200chunks of audio per second with a thread running at realtime priority.
So, if you don't want to use too much cpu just to play a wav file, maybe it is better to use latencies in the order of 20..40 msecs.
With pipewire, you can have the best of both worlds when you need one thing or the other.
As a side bonus, it provides interoperability between jack,alsa (usespace) and pulseaudio without the need to switch between them, nor to load them, because it implements all of them natively, and that will allow to do and play with ease with all the pro-audio apps/effects/equalizers available in the jack domain, much better than just pulse/easyeffects.
For once, there is work to reduce fragmentation done the right way, imho.
Granted, the software is still not perfect, but is under active development and devs are fast in fixing bugs, but they need users to report them ofc.
Last edited by kokoko3k on 2 Mar 2022 at 10:38 am UTC
This is probably a stupid question, but…why is there a split in the first place? Why can't consumer audio be low latency too? Or is this massive overkill like providing the average office worker with a monitor with a 500 Hz refresh rate?
You don't want nor need that, the monitor example is vaild if the compositor needs to render the same image 500 times per second.
Pro audio often needs extremely low latency (maybe even high bit depths and samplerates) that taxes the cpu, because to achieve it, you need to continuously load very small chunks of audio data to the audio card and that thread needs to run with realtime privileges or you'll end with what is called XRUN (empty buffer == audio glitches).
For example if you need to hear a sound sampled as soon as possible, say with a latency of 5ms, if i'm doing the math right, you need to load at most 1000ms/5ms = 200chunks of audio per second with a thread running at realtime priority.
So, if you don't want to use too much cpu just to play a wav file, maybe it is better to use latencies in the order of 20..40 msecs.
With pipewire, you can have the best of both worlds when you need one thing or the other.
As a side bonus, it provides interoperability between jack,alsa (usespace) and pulseaudio without the need to switch between them, nor to load them, because it implements all of them natively, and that will allow to do and play with ease with all the pro-audio apps/effects/equalizers available in the jack domain, much better than just pulse/easyeffects.
For once, there is work to reduce fragmentation done the right way, imho.
Granted, the software is still not perfect, but is under active development and devs are fast in fixing bugs, but they need users to report them ofc.
Last edited by kokoko3k on 2 Mar 2022 at 10:38 am UTC
3 Likes, Who?
Patreon
PayPal
An idiots guide to setting up Minecraft on Steam Deck / SteamOS with controller support
How to install extra software, apps and games on SteamOS and Steam Deck
See more from me