8 ms·
PipeWire is how audio should be on Linux, and it's ready to use. No more complications between PulseAudio, ALSA, and JACK. PipeWire implements all 3 of these in
by commoner 5y ago
PipeWire is how audio should be on Linux, and it's ready to use. No more complications between PulseAudio, ALSA, and JACK. PipeWire implements all 3 of these interfaces, which means you can use applications that depend on any or all of these interfaces simultaneously with no conflicts. Playing a video in Firefox and a track in a digital audio workstation at the same time works with no special configuration. PipeWire makes audio on Linux as easy as it is on other OSes.
The Arch Wiki page describes some of the use cases for PipeWire: https://wiki.archlinux.org/title/PipeWire https://wiki.archlinux.org/title/PipeWire
- marcodiego 5y agoIt is a shame it took so long but it is finally here. The feeling may be similar to when pulseaudio arrived, but it is not the same thing; Pipewire implements everything that is needed; users will no longer need to care about handoff between alsa, pulseaudio and jack. It manages video streams too and the latest version of OBS even makes use of it to allow screen sharing on wayland running from flatpak. Finally! I've been watching linux since the OSS days. I used oss, alsa, arts, esd, jack, pulseaudio... never it has been looking as well aimed as it is this time. Finally!
- buu700 5y agoI haven't read the article yet, but how big a deal is this? Is this something that distros are likely to adopt on top of or in place of PulseAudio? Does this make any existing part of the Linux audio stack/ecosystem redundant, or is it strictly solving a problem (or problems) that had yet to be addressed?
- necubi 5y agoYes, it replaces PulseAudio and Jack. Its goal is to provide a single audio daemon that can serve both consumer applications (where power consumption is typically most important) and pro applications (where latency is most important). Currently those are served by PulseAudio and Jack, so it's very exciting to have a single service that can cover both use cases. It also replaces part of ALSA, which is two things: the kernel interface to talk to audio devices, and a set of user libraries on top of that interface. PipeWire still uses the former, but has its own, better API for the latter (in addition to supporting ALSA, PulseAudio, and Jack APIs).
- deleted 5y ago[deleted]
- odiroot 5y agoFrom Pro Audio perspective, it's even easier than on Windows. Not sure about Mac OS, never tried it.
- PaulDavisThe1st 5y agoIt's not quite as easy as on macOS, but then again, macOS doesn't offer interapplication audio routing (the "JACK part of Pipewire"), so the comparison is not entirely fair. Pretty close though.
- marcodiego 5y agoPipewire allows any app to be an element on a patchbay: https://gitlab.freedesktop.org/ryuukyu/helvum https://gitlab.freedesktop.org/ryuukyu/helvum
- PaulDavisThe1st 5y agoI know what Pipewire does ... I wrote JACK :) I was describing what macOS does not not allow, and that's routing audio between applications. When I say that, I don't mean that it is impossible - there are numerous tools (including JACK) that will allow it - but it doesn't come with just CoreAudio itself.
- marcodiego 5y agoThanks for writing Jack! I love the fact that I can play something in vmpk, render using qsynth, process in rackarrack and record directly in audacity. The routing feature alone sets Linux apart from the competition and I'm happy it influenced pipewire to implement it. Linux is already deployed in some commercial daws and it will soon be an RTOS. Hope music production will have more and better options because of this.
- PaulDavisThe1st 5y agoThere have been "RTOS" versions of Linux for more than 20 years. The current mainstream kernel already includes almost all of the RT_PREEMPT patch set that makes it more or less an RTOS if you want it to be.
- JoshTriplett 5y agoPulseAudio already covers the ALSA interface, but I'm glad that PipeWire now unifies those two with JACK and audio workstation needs, as well as handling video.
- tgsovlerkhgsel 5y agoDoes it fix the Bluetooth audio mess? Ubuntu 21.04 still can't do videoconferencing properly via Bluetooth as only ancient 'string on a tin can' codecs are supported. And getting it to just stick to unidirectional audio (relying on the internal mic for input, which seems like the only practical option) took some serious trial and error. It still occasionally sends a stream to my headphones when nothing is playing, which prevents other devices from using them (my headphones let you connect two devices but only play audio from one of them). If it does address these issues, I hope Ubuntu will soon officially support it (I've learned better than to use non-defaults, it just invites pain).
- capableweb 5y ago> Does it fix the Bluetooth audio mess? Ubuntu 21.04 still can't do videoconferencing properly via Bluetooth as only ancient 'string on a tin can' codecs are supported. https://wiki.archlinux.org/title/PipeWire https://wiki.archlinux.org/title/PipeWire > 4 Troubleshooting > 4.8 Low audio quality on Bluetooth > I've learned better than to use non-defaults, it just invites pain Funny, after using Ubuntu for many years I switched to Arch, just because I got hit by so many upgrade issues when "things should just work". With Arch I can only blame myself, which is refreshing.
- hmry 5y agoIt did for me. I switched from Pulse to PipeWire and my bluetooth headphones started working right away. Quite the experience.
- corty 5y agoAgreed. The latest Debian upgrade installed pipewire for me, and I didn't even notice, everything just worked fine! And that after years and years of fiddling with alsa and pulseaudio configs, uninstalling pulseaudio, hacks upon hacks to get stuff working with either, etc.
- glandium 5y agoDebian 11 doesn't make pipewire replace pulseaudio, alsa or jack.
- AceJohnny2 5y ago"There are now 4 competing standards" https://xkcd.com/927/ https://xkcd.com/927/
- codedokode 5y agoI am not sure if ALSA playback should go through an audio daemon. Some audio applications (for example audio workstations that you have mentioned) want to have exclusive access to an audio card with minimum latency, without any sample conversions, any volume adjustment and ALSA (as I understand) was supposed to provide such access. Audio daemon prevents them from getting it. Passing data through a daemon adds latency. Wouldn't it be better if daemons like PulseAudio or PipeWire gave control of an audio card to an application that wants exclusive access? For example, Windows API can provide exclusive access to an audio card.
- keithwinstein 5y agoYes, PulseAudio and JACK do this as well -- there is a DBus API that makes them give up an ALSA device to an application that wants direct access. http://git.0pointer.net/reserve.git/tree/reserve.txt http://git.0pointer.net/reserve.git/tree/reserve.txt
- PaulDavisThe1st 5y ago> Passing data through a daemon adds latency This is not necessarily true. Using JACK adds no latency, for example.
- jcelerier 5y agowasn't there something with jack2's async mode (which is the default) adding an additional safety buffer though ? edit: https://github.com/jackaudio/jackaudio.github.com/issues/138 https://github.com/jackaudio/jackaudio.github.com/issues/138
- PaulDavisThe1st 5y agoYes, JACK2 in async mode will add 1 buffer's worth of latency. But that's only for async mode; sync mode or JACK1 adds zero latency.
- AshamedCaptain 5y agoI used to criticize PulseAudio a lot because for a time it was growing too much, acquiring way too many responsabilities, which would eventually make it one of those programs that is "way too hard to replace" in the Linux Desktop world, so we would get stuck with it for a time. I am glad to have been proven wrong. I was extremely surprised at the progress PipeWire made in a couple short years. I have been barely able to find any issues even after a couple of months of using it. In comparison, I filed a dozen PulseAudio bugs (some of them with patches, never applied) before I just gave up...
- tootie 5y agoI'm completely confused reading the home page. What actual use cases is this for? Like what applications are served by it?
- BenjiWiebe 5y agoThis is the software that sits between a program wanting to play media and the device that plays it. It's responsible for things like choosing audio inputs and outputs and volume mixing etc. Pretty much your whole Linux audio stack.
- ncmncm 5y agoOriginal motivations IIUC were that PA does not do synchronized video, has no security model, and does not meet Pro latency requirements. Requirements were driven by complications found managing streams in automotive uses. E.g. routing back-up cam video, soft instrument cluster video, bluetooth phone audio, dash mic, car stereo player, sirius receiver, voice navigation, dash cam. The mind boggles.
- nvarsj 5y agoImagine you're a streamer with OBS and you need to patch your mic, game sound, music stream, etc. and adjust all the levels. It's a PITA to do this kind of thing with pulseaudio - which seems to have been designed with the model of "one user, one sound device" in mind. So people use JACK for this kind of thing, which is similar to what you can get in Windows (with virtual audio cables, virtual patch bays, etc.) that let you route your sound however you need to. But it is also fiddly and painful to use, especially trying to get it to interoperate with w/ pulse. So Pipewire is meant to replace all this with a single solution that is easy to use and "just works".
- remram 5y agoI've been doing this to record video conferences, separating my mic, conference output, and rest of desktop. So I record my mic and the rest of the conference with OBS (as two separate tracks) and can still hear conference + other apps (but other apps aren't recorded). I'm doing this with PulseAudio. It adds a little latency but it works. I initially used pagraphcontrol [1] and later made my own little Python script that creates the virtual devices ("null outputs") and virtual wires ("loopbacks") and wires conference applications automatically when they show up. Can I do this with PipeWire? Are the tools there? This post claims that PipeWire is now ready, but it seems to have reached version 0.3.35 which seems a very arbitrary point to call a milestone. [1]: https://github.com/futpib/pagraphcontrol https://github.com/futpib/pagraphcontrol
- cout 5y agoDifferent people may have different definitions of "ready to use". For me, pipewire works mostly great; it fixes more than a few issues I never could solve with pulseaudio. But pipewire-pulse has crashed more than a few times for me (though not since I last upgraded pipewire, so keeping fingers crossed that it's been fixed). I wouldn't recommend it (yet) to someone who isn't prepared to tinker.
- franga2000 5y agoNow if only pipewire-pulse actually worked or PipeWire just let me use Pulse alongside it for the time being so I could actually get all those improvements... I'll definitely retry every 6 months or so, but for now, I have to spend my time getting actual work done, not experimenting with yet another shiny and new, but unfinished and unstable toy (Wayland flashbacks intensify).
- cunidev 5y agoSince the first PipeWire integration in Fedora (beta), the majority of my problems with Linux audio, especially on the wireless side, disappeared.