PipeWire 0.3.46 | Hacker News Reader

PipeWire 0.3.46

gitlab.freedesktop.org

113 pointsjrepinc81 comments

For anyone else who couldn't make head or tail of the linked page, there's more context at https://pipewire.org/ :

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.

Does anyone know if there is something particular special about release 0.3.46? Or is a normal release (once every other week)?

for even more information, here is the lwn article: https://lwn.net/Articles/847412/

Never did any audio programming, I still can't make heads or tails out of it. Is it expected that an application sets up some processing graph for an engine to play a sound? [1] Instead of writing samples to a buffer in a loop? Who wants that?

[1] https://docs.pipewire.org/page_tutorial4.html

Buffers necessitate latency.

Also, while I don’t know the project yet I can see the benefit in building something from the ground-up in a way that embraces multi-process “in/out” pipes. Someone could have dozens of effects all connected to the audio signal, then run that to dozens or hundreds of outputs (streams online, multiple speakers, recording applications, analog mixer inputs...). Traditionally that kind of usage is fragile as memory corruption can happen at any stage since everything is writing/reading the same buffer. If they have a true graph implementation then applications could interact with the graph edges and the overall system would be much more robust.

And doesn't processing necessitate buffers? How does this approach reduce the number of buffers involved? If anything, it sounds like less sharing would mean more buffers.

Any given application just needs to write samples to a buffer, effectively. That’s just the start of the processing graph.

I don't know of very many applications that use PipeWire directly (at least for audio); usually a program would target some other Linux audio API (ALSA, PulseAudio, JACK), for which PipeWire would provide the necessary plumbing and libraries to be a drop-in replacement for those older APIs.

Side note, why is posting a link to a changelog a common and accepted way to share links on HN? You are correct, reading the linked page is pointless until we understand what PipeWire is.

I love & read these changelog posts avidly. They are regular & amazing.

We should have nuanced interesting advanced tech shared here. Not everything needs to target complete newcomers.

Pipewire is great for many reasons. I love not having to worry about starting and stopping a JACK server every time I work in reaper or sclang, and I can still open qtjackctl and use the transport.

Everything else about it alsa and pulse wise is totally transparent, dont even have to think about it.

> A Dummy fallback sink is now automatically created when there are no other sinks. This avoids stalling browsers.

That is a great change, had lots of troubles watching Videos - especially with bluetooth + seeking in a Video.

Seems like its already part of upstream archlinux.

I've been using Pipewire for over a year now. Both for normal desktop tasks and music production. It's just great. So much better than just Pulseaudio or JACK. And at times even better than these two combined.

I have 4 soundcards present on my system (built-in, external webcam, USB audio interface, USB synthesiser) and Pipewire can handle it all at once.

Bluetooth headphones are also handled well. They connect by default with aptX (A2DP mode) but using KDE tray icon, I can easily change it to full-duplex headset mode with mSBC.

And then I can use (not that I would always want to) any of these devices together (e.g. in a DAW).

> They connect by default with aptX (A2DP mode) but using KDE tray icon, I can easily change it to full-duplex headset mode with mSBC.

As of wireplumber 0.4.8, they will now automatically switch to the headset profile when an application begins recording audio! It's now almost seamless (though I do still need to manually select the audio device every time in Firefox).

I actually turned that off as I prefer keeping the headphones in A2DP mode and using a separate microphone.

How do you turn this off?

The setting is in 10-default-policy.lua.

> they will now automatically switch to the headset profile when an application begins recording audio

My phone does this and I find it incredibly annoying, because the profile that uses a microphone has terrible sound quality, and a constant low-volume background white noise.

Meanwhile what I want is a way to configure it to never ever, under any circumstances, use the headset profile.

> I've been using Pipewire for over a year now.

Same. I've had a nearly flawless experience so far. I can't praise Wim Taymans and the Pipewire team enough. It's great to see the progress since one of my earliest Linux memories circa 2005 was audio sucking eggs on Ubuntu.

What DAW do you use? I tried Ardour but gave up because MIDI experience wasn't good compared to Cubase.

Not OP, but I use Bitwig. It's well worth the money.

Reaper's also worth a look if you're primarily recording, but it does have some MIDI capabilities.

Ardour does actually not have a good MIDI experience ... this will change with the upcoming 7.0 version. The MIDI experience overall doesn't have anything to do with Jack

What are some of the problems y'all have encountered with its MIDI experience? Seems to be alright for me, though I ain't doing anything particularly fancy with it.

I currently use Bitwig because it's the only Linux-native DAW that I can grasp. If Ableton released a Linux version, I'd probably switch.

Interesting you and others use Bitwig, which I've never even considered using before. Maybe I should pay broader attention.

It is quite pricey (or you can buy the cheaper 16-track version) and still missing some substantial DAW features, so it's not an obvious choice.

  > So much better than just Pulseaudio or JACK. And at times even better than these two combined.

This is great news. Might they write an init daemon next? Pretty please??

Npghnyyl, V _qb_ yvxr flfgrzq.

The irony of your comment is that a huge part of PipeWire being this good is the work of the PulseAudio devs. When PA first came out, the experience was terrible because it exercised drivers in a way that plain ALSA or previous audio daemons had not done. Over the years, the drivers got their shit together, so now PipeWire has competent drivers to work with. That's not to say that PipeWire is not an impressive achievement in its own right (it absolutely is!), but it's not as much of an uphill battle than what PulseAudio had to fight.

No irony at all, I understand the situation that led up to both PA and systemd. That's why I wrote:

  > Npghnyyl, V _qb_ yvxr flfgrzq.

This thread got me curious about Bluetooth on Pipewire. Using a pair of Soundcore Spirit X headphones, I paired them in Fedora 35's Gnome bluetooth settings page. Then tested and it worked great. I even changed the audio codec from SBC to SBC-XQ and it still worked after disconnecting and reconnecting (which it did automatically)

Very impressed!

My issue with bluetooth audio on linux is when playing games or other application that max out the cpu, the bluetooth process can be starved of cpu time and begin to stutter. I ended up using a bluetooth audio transmitter [1] (it presents itself as a usb audio device on linux) to work around the issue.

[1] https://www.amazon.com/Creative-Bluetooth-Transmitter-Indica...

Do you have real time priority configured for the Pipewire (and possibly bluetoothd) process? I had annoying stutter issues before setting that up (Gentoo could not do it automatically at the time, but that may have changed).

I haven't look into it yet. I was trying to get a Bluetooth 5.0 adapter first before trying again, but can't find any at the time. There are plenty of bluetooth 5.0 audio transmitter though, which sidesteps the issue completely.

I wish pipewire would implement/facilitate the audio features of paprefs for sharing audio across the network.It's one of the gems that makes linux very appealing for people who have multiple machines and want to connect audio.For example, with a bluetooth headset that is connected to a laptop running linux, you can also connect your desktop's audio to be outputted to the BT headset through paprefs,thus merging multiple audio sources.Haven't tried with more than 2 devices, but i think it would work.Sadly there's no solution yet for also adding an android device to the mix(you could use one of the few solutions that have the android device output audio through a webpage, which would be opened on the desktop, but those solutions have insane latency issues).

If you really struggle to notice you can observe a little bit latency overhead and lower quality but that's honestly to be expected,but 90% of the times using this features is not intended for an 'audiophile' experience(for which we use the cable anyways).

Until then i have to keep using pulseaudio, which is not terrible for some time now, mainly because it's past the point where everything was buggy.

Have you checked if there's at least a feature request for that? I might not even be on the radar.

I did search couple months ago(or even sooner) and obviously nothing was found.To be fair i don't expect pipewire to implement even in the upcoming year such a feature, because it's not something easily done: that's why i switched back.However i was kind of disappointed by the fact that the compatibility module between pulseaudio & pipewire wasn't working in this case, because at least theoretically pulseaudio & paprefs does all the work of piping through the network(Because in my case i would have used the pipewire device, with the PA module, --Fedora-- just to transfer some audio to the actual device with PA --Ubuntu-- that has the BT connected), it's just that the module did not work.

My setup is fine now (I had some stability issues with the latest kernels w/ Fedora anyways) but i hope there's more adoption for Pipewire (preferably Ubuntu due to the massive user base) to be a serious contender in terms of features (because it is already pretty stable).

> A Dummy fallback sink is now automatically created when there are no other sinks. This avoids stalling browsers.

This is nice. Playing videos with no headphones / speakers connected would previously just freeze the video player. Even on non-browsers.

Several recent HN threads about this project:

PipeWire and fixing the Linux Video Capture stack - https://news.ycombinator.com/item?id=28726125 (128 points/4 months ago/37 comments)

PipeWire: A server for Linux audio and video streams - https://news.ycombinator.com/item?id=28490078 (531 points/5 months ago/172 comments)

PipeWire: The Linux audio/video bus – https://news.ycombinator.com/item?id=26327779 (457 points/11 months ago/201 comments)

Fedora on the PinePhone: Pipewire Calling – https://news.ycombinator.com/item?id=26080207 (139 points/Feb 9, 2021/90 comments)

PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2 – https://news.ycombinator.com/item?id=22391896 (128 points/Feb 22, 2020/43 comments)

Is anyone here running pipewire-pulse successfully? I have a bunch of apps that expect PulseAudio to be present, but no matter what I tried (appx. half a year ago), I could not get any output from pipewire-pulse. Has this improved?

I've been running openSUSE Tumbleweed on my desktop (nothing fancy though for audio), and at some point last year (July perhaps), an update removed pulseaudio and installed pipewire. If I hadn't been paying attention I wouldn't have noticed. It was a seamless drop in replacement. Everything works at least as good as it did with pulseaudio. I still use pavucontrol and some other pulseaudio stuff and it just works with no issues with pipewire-pulse.

I switched to pipewire from plain ALSA last year and configured pipewire-pulse because there was one game I wanted to play which insisted on PulseAudio. I got audio to work for that particular game but since I don't need pipewire-pulse for anything else I likely won't notice if it breaks. I found the documentation lacking and configuration difficult, but it's still early days for pipewire and it is clearly an improvement over ALSA.

Are you referring to their libpulse reimplementation? Because if so, that one got sacked a while back because they could not iron out the kinks. These days, PipeWire implements the PulseAudio server API directly, and this part is working absolutely perfectly for me. I'm even using pavucontrol to configure my PipeWire device profiles.

UPDATE: I tried it on my laptop and everything worked with zero configuration. Either whatever bug I encountered last time was specific to my desktop or has since been fixed. Especially Bluetooth is now unbelievably seamless - 1000x better than Windows and on par with Android.

I would have thought most linux users are, since most mixers (plasma, gnome, etc.) afaik haven't been ported to pipewire? My experience was that installing pipewire-pulse (and, removing pulseaudio) caused my mixer to continue to JustWork.

What distro are you using? Switching was trivial for me. Pipewire exposes the same API as pulseaudio, so nothing was really impacted.

You have to go in and change some config files or it won't work by default. Wasn't clear to me either at first.

After the pulse bluetooth codec support drama last year and the discontinuation of the modules I was using to support better codecs, I moved to Pipewire and it just worked. Wouldn't know I wasn't using Pulse, except I don't have to install an extra module from the AUR which would occasionally get out of sync anymore.

I'll hijack the thread: is anyone else having Bluetooth audio issues on PipeWire?

I'm super happy with it in general, but a certain BT headset that worked just fine with PulseAudio just refuses to connect with PipeWire. As with all things BT, debugging is terrible :-(

IIRC, I always need to restart the pipewire-session user service once before getting a stable connection on my latop, I'm not using it that often currently as I'm not travelling much, but it was something like

    systemctl --user restart pipewire-media-session.service

Maybe also restart pipewire-pulse.service, with that I can pair and use my WH-1000XM4 just fine using pipewire Debian Sid/Unstable.

Probably more/better info is on: https://wiki.archlinux.org/title/PipeWire#Bluetooth_devices

pipewire-media-session is basically unmaintained, development effort has moved to wireplumber (even though I think routing audio in Lua is unnecessary dynamism and complexity).

I was having stuttering issues with Bluetooth when the CPU is under 100% utilization (e.g. playing games) and I was able to sidestep the issue completely by using a bluetooth audio adapter like this one [1]. The adapter present itself as a USB audio adapter and able to function just fine even when the CPU is under 100% utilization.

[1] https://www.amazon.com/Creative-Bluetooth-Transmitter-Indica...

I think it's some kind of a multi-threading issue in the bluetooth stack, as it seems rather random if it will break or not. For me, sometimes my headset connects in HSP mode and won't ever leave it regardless of config and further reconnections won't fix this. Only restarting `bluetoothd` will help.

I had similar issues where I had to basically restart both the pipewire and the Bluetooth daemon after each reboot before being able to connect my headset.

My "solution" was basically to drop using pipewire for now.

Yes, loads of issues. I'm not sure how, but trying again and again I finally got one or two headsets to connect, but not a third. Definitely seems like it's not quite stable yet.

File a bug.

https://gitlab.freedesktop.org/pipewire/pipewire

I try to avoid filing bugs when I don't have any debugging information beyond "it doesn't work, but works with PA". My problem here is that I'm incredibly inept at debugging Bluetooth issues.

Does PipeWire offer a way to route a specific app's audio through specific devices? The same way I can do `xvfb-run some-app` or `Xephyr :1 & DISPLAY=:1 some-app` to run an app in a specific X server.

I couldn't find a way to do this with PulseAudio, instead I have to find the app's devices in pavucontrol/pagraphcontrol and re-route them (but if the app disconnects/reconnects I have to do it again, based on the name which is "Chromium" for most of the apps on my laptop (thanks Electron)).

Any experiencing switching Ubuntu 20.04's audio stack to PipeWire? I'd love to do it, since my pulseaudio setup is giving me trouble, but haven't yet found the time.

Yes. I was also having issues with pulseaudio on 20.04. I spent a few min reading about pipewire, spent a couple min adding the ppa, installing the packages and iirc disabling pulseaudio. And everything just worked and I haven't thought about it in 6 months.

I keep meaning to spend some more time digging into the configuration and capabilities, but I think that's just a compulsion from decades of daily driving Linux and having virtually nothing "just work" this easily.

I'm also on Ubuntu 20.04 and able to switch to PipeWire recently using pipewire-debian PPA [1]. Just a note in case you're running into an annoying issue like me: make sure your /etc/pipewire directory is EMPTY before installing pipewire. Mine somehow didn't, and pipewire just hang due to using the old config file. Took me a while to figure out the issue. After installing pipewire packages, make sure to copy the most recent config from /usr/share/pipewire into /etc/pipewire before enabling all pipewire services (this should be covered in the linked guide).

https://pipewire-debian.github.io/pipewire-debian/

I've been using Pipewire from Alpine, and I can't tell what the problem is, but I have to kill it and restart it manually all the time. Every time I come out of suspend, often when I have Bluetooth issues. Selecting a specific BT profile requires me to kill both PW and BT if I want to select a different one. Never had these problems with PulseAudio.

Anyone else remember how we used to solve any audio-related issues by uninstalling pshhhaudio? Guess what, pulseaudio got kind of stable and usable and... it's gone, praise pipewire. Granted, it's not that bad this time around, but digital spdif output doesn't work on my motherboard with pipewire, so nice try, pipewire, but not yet

Does anyone know where I could find a list of what distros are already using Pipewire by default?

From https://www.linux-magazine.com/Online/Features/Getting-Ready... :

The easiest way to try PipeWire is to install Fedora Workstation 35 in Boxes or VirtualBox. Instructions for working from source code are available online, but are only recommended for the hardy. Even other distributions that have PipeWire in their repositories generally have a wiki with distro-specific instructions. Arch Linux, Debian, and Gentoo are among the distros with PipeWire configuration wikis, although you may find they suffer from a lack of current information.

Also https://old.reddit.com/r/linux_gaming/comments/m1t65m/which_...

Manjaro and arch apparently depending on whether you use X or Wayland. I was trying to figure out why screen sharing was not working last week and the answer was something pipewire is probably foobarred. Kind of a thing where the answer to "why is X not working" always seems to boil down to following some convoluted process involving the installation of multiple obscure packages, dealing with their arcane configuration files, etc. I half got there in the end. I seem to able to share my desktop via google meets at least. No luck with the discord snap. Though that may have as much to do with pipewire as with snap.

It seems anything using wayland would need to rely on pipewire for a few features; including sharing your screen. At least that is my understanding.

This doesn't answer your specific question, sorry, but Fedora 35 uses it by default.

It's worked flawlessly for me on F35. The one thing I've had to amend is that I need to pass an extra flag to Slack to allow me to share my screen. I think that's a Slack thing more than Pipewire though.

On Arch, just installed the package and everything worked OOTB. Pretty amazing!

Ah, perhaps it's because I installed Slack via Flatpak instead of RPM. Will give that a go.

That's been my experience on Fedora too, it's worked great out of the box.

With multiple cards too! USB webcam, a Jabra USB headset adapter, motherboard sound card, the Acer screen over DisplayPort, and the Schiit USB DAC.

Indeed, Fedora uses it from 34. As a user, I had no idea.

https://fedoraproject.org/wiki/Changes/DefaultPipeWire

I kind of answers, but also doesn't. I already use Fedora and was wondering if there are any other distros that made the jump :)

openSUSE Tumbleweed uses it by default since some point last year. I'm not sure if/when Leap has or will make the switch.

NixOS had it as an option for over a year now. (NixOS not really doing defaults the same way as other distros, pulseaudio is similarly enabled IIRC)

`sound.enable` currently enables pulseaudio.

If you want to use pipewire, you're supposed to set sound.enable to false, which will disable pulseaudio. If you leave it enabled, you'll likely get both. Which doesn't necessarily break anything, assuming your devices can handle at least two audio streams.

Or just leave sound.enable as it is, and eventually it'll get repurposed for pipewire.

An another great thing about Pipewire is that it made desktop sharing possible under Wayland.

Is there any pipewire-audioflinger compat layer?

Does pipewire in any way help overcome shitty quality of bluetooth headset (with mic) audio?

Yes, it does implement a better protocol AFAIK (don't know the specifics though)

love it, i just wish that was a simple toggle to enable global loudness filter like on windows / macOS

having to manually tweak the volume for everything is a pain

i know about easyeffects, but that's not what i want and it consumes too much CPU

Reply on news.ycombinator.com