Hacker News Reader

Comment by commoner | Hacker News Reader

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

View on HN

It 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!

I 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?

Yes, 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).

That sounds pretty awesome. Thanks!

PipeWire also handles video (e.g. webcams, screen capture) in addition to audio.

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.

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).

> 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 > 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.

It did for me. I switched from Pulse to PipeWire and my bluetooth headphones started working right away. Quite the experience.

Agreed. 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.

Debian 11 doesn't make pipewire replace pulseaudio, alsa or jack.

Should have mentioned, I'm running testing/unstable. After the stable release, all the new experimental stuff for the next release floods into unstable.

oh, how exciting! time for a dist-upgrade tonight then!! :-)

> Does it fix the Bluetooth audio mess

Yes, one of the biggest features of Pipewire is proper Bluetooth headset support. It's the reason I switched to it.

It actually does more than fixing the mess now. With pipewire >=0.3.34, there is now support for a2dp duplex with both faststream and aptx-ll codecs (if the headset also supports them, of course). No more hsp/hfp crap.

I think linux + bluez + pipewire is the first ever software-only stack that can achieve this, as a USB dongle would be required on other platforms. We shall declare 2021 as the year of linux on the desktop!

It supports bidirectional audio if the headphones do and mSBC for better-than-tin-can audio if they don't.

Seems that Pipewire and PulseAudio have both just recently fixed this. So yes, but it may not technically matter anymore. But it will be upcoming in a future Ubuntu it's not in the current shipping releases and I'm not sure it will make it into 21.10.

I 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...

From Pro Audio perspective, it's even easier than on Windows. Not sure about Mac OS, never tried it.

It'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.

Pipewire allows any app to be an element on a patchbay: https://gitlab.freedesktop.org/ryuukyu/helvum

I 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.

Thanks 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.

There 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.

Echoing the parallel comment, if you're willing to get your hands into the guts, you can get amazing "RTOS-like" audio performance out of linux. I love pushing the limit of how low latency can get. Start with the PREEMPT_RT patches, be sure your irqs for audio are prioritized right, then experiment with pinning individual processes to specific cores, as well as locking their address space in memory.

Thanks for writing JACK! I'm curious what you think of PipeWire, feel free to be opinionated.

I'm also a low level audio/midi dev (tho far less prolific, and less public) and having seen how you architect things, and your code, I'd value your opinion.

There's a low-latency, free/OSS driver to do this.

MacOS is a little confusing with it because you have to configure it in the MIDI setup utility, but it works very well.

Not to mention commercial product from Rogue Amoeba which is fantastic.

And now I feel like an idiot for posting this having read who you are

It does help the rest of us though. I'll also mention for the same reason that there was a thing called ReWire on Windows, not sure what became of it.

Rewire is fairly different. It still exists, and also existed for macOS too. But to use it, applications have to be explicitly coded to use it (and linked against the rewire SDK).

That's quite different from JACK, SoundFlower, Hijack and the innumerable other inter-application audio routing systems for macOS, which can be used without the applications knowing anything about them.

The functionally named but utterly undescriptive GraphEdit, which was at some point part of the DirectX SDK allowed you to build arbitrary pipelines (that normally you'd have to configure via code in your app) for input/output of multimedia data. I haven't done directX programming in over a decade though so I have no idea if it's comparable to ReWire, but GraphEdit was an unsung hero back when I was.

The DirectX SDK in this respect is like GStreamer on Linux: it allows an application to build arbitrarily complex pipelines for data processing. Emphasis on within the application.

However, it did not and does not provide for inter-application audio/MIDI routing, which is what tools like JACK, Rewire, SoundFlower, Audio Hijack and others are all about.

In some situations you’d be accused of mansplaining

Different 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.

PulseAudio 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.

I 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.

Yes, 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

> Passing data through a daemon adds latency

This is not necessarily true. Using JACK adds no latency, for example.

wasn'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

Yes, 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.

Now 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).

I'm completely confused reading the home page. What actual use cases is this for? Like what applications are served by it?

This 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.

Original 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.

Imagine 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".

I'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

Since the first PipeWire integration in Fedora (beta), the majority of my problems with Linux audio, especially on the wireless side, disappeared.

"There are now 4 competing standards"

https://xkcd.com/927/

I'd love to hear how you think Pipewire and ALSA/Jack are competing.

Pipewire seems more like a multiplexer/bridge for the existing standards.

That was necessary for back compatibility. There is also a native API, I think.

Reply on news.ycombinator.com