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.
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?
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.
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.
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.
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 :-(
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.
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.
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
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).
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.
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.
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.
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.
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.
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.
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).
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.
> 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).
> 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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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).
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)
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.
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.
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 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)).
83 comments
[ 3.1 ms ] story [ 168 ms ] threadPipeWire 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.
[1] https://docs.pipewire.org/page_tutorial4.html
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.
We should have nuanced interesting advanced tech shared here. Not everything needs to target complete newcomers.
Everything else about it alsa and pulse wise is totally transparent, dont even have to think about it.
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 :-(
My "solution" was basically to drop using pipewire for now.
https://gitlab.freedesktop.org/pipewire/pipewire
Probably more/better info is on: https://wiki.archlinux.org/title/PipeWire#Bluetooth_devices
[1] https://www.amazon.com/Creative-Bluetooth-Transmitter-Indica...
With multiple cards too! USB webcam, a Jabra USB headset adapter, motherboard sound card, the Acer screen over DisplayPort, and the Schiit USB DAC.
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
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_...
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.
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.
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).
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.
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).
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.
Reaper's also worth a look if you're primarily recording, but it does have some MIDI capabilities.
Npghnyyl, V _qb_ yvxr flfgrzq.
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 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.
https://pipewire-debian.github.io/pipewire-debian/
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.
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).
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)
Very impressed!
[1] https://www.amazon.com/Creative-Bluetooth-Transmitter-Indica...
This is nice. Playing videos with no headphones / speakers connected would previously just freeze the video player. Even on non-browsers.
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
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)).