PipeWire: A year in review and a look ahead | Hacker News Reader

PipeWire: A year in review and a look ahead

collabora.com

262 pointspabs3123 comments

I have been impressed how I've been able to make arbitrarily complex audio graphs in QJackCtl and it just works. I can even activate patch bays and it forces the audio configuration and applications (even browsers) stay happy.

It's impressive how it manages to support connections that require reclocking and do the needed large ratio resampling needed behind the scenes, something that PulseAudio was never really able to do. It's also nice for monitoring while streaming and seems to have much lower latency than OBS's monitoring.

Note that qjackctl's author has made qpwgraph which is a similar tool but tailored to pipewire, it works great (and is already available in e.g. ArchLinux AUR, or here otherwise: https://gitlab.freedesktop.org/rncbc/qpwgraph )

Is there a good writing about setting OBS with monitoring using Pipewire? I'd be really excited to make my Zoom streaming better with OBS.

Dumb question: what did the Pipewire developers do that makes it so much better than everything else on Linux?

Sound has been an absolute disaster area on Linux for decades and it seems like the Pipewire guys just flat out solved it. (I would say "suddenly", but Wim Taymans has been working on this directly for almost 7 years and worked on Gstreamer before it)

What did they do so much better and differently?

In my case, the big advantage is the automatic insertion of resamplers between different clock domains, meaning you can connect anything to anything. Pulseaudio tries really hard to make sure there is only one clock driving any connection graph, so that's why there's no arbitrary connection support without loading things like module-loopback that add the resampling themselves.

Another thing that helps is that in some ways PipeWire is less featureful than PA. For example, it limits the max audio buffer size to ~180ms which means it doesn't have to implement rewinds, one of the buggier features of PA (with the downside that power consumption can't ever be quite as low as PA).

Some of the pipewire devs are old pulseaudio and jack devs. They are fixing their mistakes now. With a common goal, at last.

This is an aside, but I've been watching all the audio graph editor projects pop up and it's made me realize I want something like this for package management. A package maintainer should be able to specify something is a dev dependency, runtime dependency. I should be able to form a "user dependency" where I say Xwayland depends on sway - even though it doesn't. So when I remove sway it pulls out Xwayland with it. I should be able to remove dependencies within package descriptions, and see that one used to exist but has been overridden by me. I'd love to even see the history of how that graph has changed over time (step through package adds/removes). Further filter by package source to visualize the network clouds.

I want to visualize all of these dependencies as a graph, instead of trying to hamstring things together with CLI invocations. Editing the graph would invoke the package manager.

A functional package manager like nixos or guix might be a good place to start.

You can visualize dependencies as a graph with Guix out of the box [1]. While you can't easily setup "user dependencies" (except by editing the package definition) you can create profiles that install packages from a manifest file so you could have a profile with a manifest with xwayland and sway and then simply remove the profile if not needed. Guix already specifies runtime/dev dependencies.

[1]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-graph...

That is definitely close to what I'm thinking of. What I was trying to say is our 1st reach should be for a graph editor. Behind the scenes it may break down to a command line program, but what you'd deal with all the time is the graph editor that you can mouse around and zoom in/out on, and add/remove edges between nodes/packages. That would be a neat experience.

The standard way of doing this is to define your own package for what you want installed on the system. Check in the package spec to version control and it gives you the history of everything you wanted in the past. For your sway-xwayland case, make another package that depends on both, and make that a dependency of your system package instead of sway and xwayland directly.

You will also need to use your package manager's method of marking all packages as "automatically installed" except for your system package. How easy this is depends on the package manager. Eg for Alpine's apk this is trivial, because all packages are "automatically installed" unless they're listed in /etc/apk/world, but for OpenSUSE's zypper you need to update /var/lib/zypp/AutoInstalled to include every installed package and periodically refresh it when zypper decided to switch an automatically-installed package to manually-installed for some reason.

I think Alpine can do what you're asking for using virtual packages (which is basically just a label that you apply to say "the following packages are a group to be installed and removed together"): https://docs.alpinelinux.org/user-handbook/0.1a/Working/apk....

As someone who has a fairly basic use case for something like Pipewire - I switched to it about a year ago and hope to never switch back. Everything just works properly - and some of the value added stuff we have now (Easyeffects inside a Flatpak sandbox comes to mind) are very cool and work extremely well. My thanks to the developers, who have done an AMAZING job of building a realistic alternative.

There is a lot of REALLY good software coming out for Desktop Linux recently. Wayland, Pipewire, Wireguard, etc!

>> There is a lot of REALLY good software coming out for Desktop Linux recently. Wayland, Pipewire, Wireguard, etc!

etc indeed:

OBS Studio VLC Ardour, LMMS, MuseScore

LibreOffice (Writer, Calc, Impress, Draw, Base) GnuCash, Scribus, Dark Table, Inkscape, Krita, Blender, Synfig Studio, Gimp KiCAD, LibreCAD, FreeCAD, OpenScad, Solvespace, Slic3er

And untold others that are incredibly useful.

Many of programs you mention are useful, but not new and really aren't that great at showcasing a great user experience.

I would single out both Krita and Blender. Both are fantastic projects that really elevate what you can do artistically with free software.

> Everything just works properly

Not to mention the drastically lower CPU usage compared to its predecessor [1] and general lack of bugs.

> There is a lot of REALLY good software coming out

Agreed, but I would still single out PipeWire as being particularly outstanding. None of the other examples are as new, or as uncontroversial. Anecdotically, when I look at the comment section of any PipeWire article here, I see basically universal (and enthusiastic) praise.

In my case, it comes from the fact that so many sound servers have existed before, and none were even close to satisfactory, until now. It seems genuinely like a hard problem.

[1] https://news.ycombinator.com/item?id=28502614

Yeah, that's why I switched my Fedora systems to Pipewire before it became the default. At some point, Pulseaudio CPU usage went up so much that the fans on even my desktop system were noticeably spinning up. Maybe it was a Pulseaudio regression that was eventually fixed but I never looked back.

Pipewire is a blessing. It fixed so many things I can't really start listing them. Funnily, in my experience, it is a arguably better PulseAudio implementation than PulseAudio itself.

I'm not a pro user but PipeWire has been mostly great. I originally switched because of PulseAudio was causing a hissing noise on with my bluetooth headset, and switching fixed it. However, there are still two issues that I'm struggling with and haven't been able to find a definitive answer for.

One is the audio sometimes randomly jitters while simply playing music. It seems this only happens when I use my bluetooth headset, but is fine with built-in audio.

The other is, when the automatic switching to bluetooth headset is hit and miss. Sometimes it switches, sometimes it doesn't, and sometimes one applications switch, but others don't. So I'm left to use pavucontrol to switch things over correctly.

My searches haven't returned any fruitful results so I'm not if I'm just searching for the wrong things or I'm the only person who has these issues.

You are definitely not the only one was has the issue about the automatic switching to bluetooth headset. One workaround is to run `pactl load-module module-switch-on-connect` (not persisted across reboot) as recommended on the arch wiki:

https://wiki.archlinux.org/title/PipeWire#Sound_does_not_aut...

meta comment: I find it's almost always worth checking the arch linux wiki for any software you're using (either as a guide or if you're having issues).

It's one of the best resources out there, though obviously if you're not running arch you'll need to tweak things from the suggestions.

Has switching to a bluetooth headset on Linux ever been non-buggy? I mean I imagine for specific hardware-software combinations it works robustly, but I feel like this is a periodic issue I have to deal with on Linux machines

For me on PulseAudio it consistently switched it as expected, however, it the selected audio profile was quite random.

> One is the audio sometimes randomly jitters while simply playing music

I encounter the same issue from time to time. Almost consistently reproducible when I update the kernel and the VirtualBox driver needs to be recompiled (and there's no cap for that process that it should use max X% of CPU).

As pipewire is within the user session I would assume higher system load would induce some latency and cause the jitterness.

But in the end I'm just making assumptions, and correlating.

This sounds about correct. I had a similar hunch, but I noticed it correlating to high memory instead (could be just a symptom, perhaps it was doing more swapping?). I increased my swap partition, which made it happen less often. It could be very well be the CPU.

Distros should really be setting niceness levels on more processes by default, especially background software updates. And anything audio-related really needs to be at a realtime priority.

PipeWire, just like PulseAudio, uses rtkit if available. Your distro may have made it an optional dependency, so you may not have it installed.

I could not get the automatic switching either, so I wrote this script.

https://gist.github.com/abdullahkhalids/21a51240c13e19bfbb63...

I have bound Win+Home to the "general" option that connects to my earphones and correctly lets all applications use them as their sink.

Big fan of PipeWire, although I wish the tooling could work directly with PipeWire, instead of going through pactl. It's there, it's just not user-friendly. I ended up writing a tool for changing volume/muting that directly uses pw-cli: https://github.com/smasher164/pw-volume.

Agreed, at least to a certain degree :)

I never really got good with pactl or the various other interfaces, so while it's great that Pipewire is compatible with them, I was also hoping that Pipewire would mean I never needed to get comfortable with them.

If I have any criticism of Pipewire, it's that as someone who is not really interested in learning all of the quirks and weirdness of the old systems and would happily never really learn those systems except for older compatibility reasons, it's slightly weird to be running Pipewire and have all the tutorials that I've run into around it still start with, "let's learn some Pulseaudio commands".

You can also munge the pw-dump output with jq, instead of needing something to be compiled.

    pw-dump | jq '
        (
            .[] |
            select(.type == "PipeWire:Interface:Metadata") |
            (.metadata // [])[] |
            select(.key == "default.audio.sink") |
            .value.name
        ) as $default_sink_node_name |
        .[] |
        select(.info.props["node.name"] == $default_sink_node_name) as $default_sink_node |
        .
    '

Yes. This is how I did it initially, before rewriting it using serde. However, as I mention here (https://www.reddit.com/r/swaywm/comments/sks343/comment/hvn3...), shell with jq was too slow -- particularly if you're holding down the volume key.

Ah, good to know. I didn't think it would be noticeably slow, especially given it still has to spawn `pw-dump` and `pw-cli`. But I guess `pw-dump` outputs so much that speeding up just the JSON munging is still worth it.

BTW, you may consider using `Cow<'a, str>` instead of `&'a str` for the deserialized fields. For JSON strings that have escapes, serde can't deserialize them into a `&'a str`, so the whole deserialization will fail. `Cow<'a, str>` still works with `#[serde(borrow)]` in that strings that can be deserialized in-place will be the `Borrowed(&'a str)` variant, and only strings that can't will be `Owned(String)` (there's a special borrow-specific deserializer of Cow inside serde to achieve this).

jq is surprisingly slow. I've had success calling python to parse some json from a shell script instead of jq.

I agree that tooling is still quite raw (e.g.: the Rust bindings don't expose the muted states or volume of anything), but developer documentation is even worse.

There doesn't seem to be ANY public documentation on the pipewire API protocol. There's just docs for the C bindings, but lack of protocol documentation is a bit worrying, since none of us can write tools that talk to the server. A LOT of documentation pages are literally empty (just a title an nothing else). This includes the documentation for the native protocol, in case you wanted to write your own client: https://docs.pipewire.org/page_module_protocol_native.html

Apparently, reverse engineering the client/server implementations is the way to go right now.

My switch to PipeWire on Arch has been mostly painless except for one particularly annoying bug that I haven't been able to track down yet -- when the computer is hibernated, something in the config goes wrong and I need to rerun `alsactl init` to get sound playing again.

I'm certain this has something to do with me doing a bad install and not cleaning up old config files or something, possibly with either me either using PulseWire or not using PulseWire to manage the session, but it's pretty annoying (although apparently not annoying enough to get me to debug the issue).

Otherwise, it seems to basically just work. I'd love to do more with it, but truthfully I didn't really dig into Pulse/Alsa/Jack enough initially to really notice what the benefits are, so I can't tell a difference.

One thing I'd love is for a cleaner command-line interface to handle sinks, particularly when scripting. I'm sure if I took the time I'd understand them, but I find PulseAudio's sinks really annoying to work with and to manipulate. Again, I think this is mostly just the fact that I never really dug into Linux audio too deeply before so I'm not always completely sure what's going on with it, and I'm not doing anything complicated enough for me to immediately tell a difference. In some ways I guess that's a recommendation; if I managed to get the hibernation bug fixed then this would be a totally transparent switch from my perspective. That seems kind of impressive.

Is anybody here using pipewire to stream to a different machine on the same network?

I currently use Pulseaudio to send audio from my laptop to a raspberry (with a DAC hat) connected to my hifi, but it turns out it's a pretty niche use case. So I'm looking for anybody with a similar use case who has upgraded from PA to PW and can talk about the experience.

I have been attempting this in some way or another for a month or two. So far, no luck.

The most realistic option I have found would be to use NetJack, but while its been noted in a roadmap as a relatively straightforward protocol, it is not yet implemented (at least, it wasn't last time i looked).

It may be possible to hack a pipewire-jack client to do it now... but that seems like more effort than its worth.

An alternative would be Scream, if all you want is one-way streaming.

If anyone has any other ideas, i would be very much interested too!

You could also use jacktrip. Jacktrip is a jack client, so it will work under pipewire.

I have a similar setup, however it seems that video doesn't want to play in browsers with the networked audio for some reason. Anyone else experience that?

Tangentially related to your use case but check out https://moodeaudio.org/

Got it running on a Pi+DAC & use spotify connect mostly, but occasionally throw stuff from my NAS on to it.

I can't talk about that, but I will make a recommendation to try streaming with ROC.

I've done quite a bit of streaming in the past with pulseaudio-dlna and the extreme lag isn't fantastic.

https://gavv.github.io/articles/roc-tutorial/

I'm also curious about using PW, I upgraded, but I haven't setup any streaming yet.

I've been using roc with pipewire and pulseaudio for a while now and it works really well (much better than pulseaudios native tcp connection for example). You set target latency on the receiver and 150ms is enough to have (almost) no breaks in audio over a couple of hours

I found ROC at one point, but the native PA tcp connection actually works good enough for me.

The only problem I had with my setup was when I changed my router to a Mikrotik hap ac2 - there was a lot of stuttering and dropouts. After switching to OpenWRT on the Mikrotik, everything became usable again :)

I've had good luck with this method: https://wiki.archlinux.org/title/PipeWire#Sharing_audio_devi...

Yeah, that looks like the PA conf I'm currently using. Did you notice any difference after switching to Pipewire?

I bookmarked https://news.ycombinator.com/item?id=29514876 a while ago. I’d love a Sonos-esc ecosystem that doesn’t arbitrarily expire also.

I forward the pulseaudio socket (pipewire-pulse, to be precise) over ssh and it works fine.

Could you share the command to do that? I've seen `foo | ssh bar`; is it just `source | ssh 'cat >/path/to/pipe'`?

    ssh -R /run/user/1000/pulse/native:/run/user/1000/pulse/native remote_host ...

assuming the SSH client is the one with the audio device and remote_host is the one that wants to play audio. If it's the other way around then replace -R with -L.

Just in case anyone wants to do something similar between Windows boxes, NDI and Voicemeeter both do this pretty well. Voicemeeter has more features but audio quality can be hard to get right and setup can be convoluted. NDI is very very easy to configure but doesn't have as many options.

I do this "into" a RDP session in a VM on the same machine (because RDP audio is really really bad) and both of the above tools worked really well for me.

I recently made the switch in NixOS and found it pretty painless. Can't get my mic to work in Firefox though, and the other day I was looking through the manual trying to figure out how to use my HDMI screen's speakers rather than the built-in one and couldn't find the right incantation. Sounds like such rough corner cases will be a thing of the past soon. Congrats to the dev team!

You can still use pavucontrol for configuring in- and output devices per application.

That is how I have to manage the target output when Pipewire doesn't switch the audio to my Bluetooth headphones upon connection (sometimes it does). The confusing part is that the selected/target output in Settings->Sound on Pop!_OS continues to show as the headphones but the sound from the application, say Firefox, doesn't switch to that (clicking on Test works perfectly which is when I realized that the issue probably was not with Bluetooth/headphones but about per-app switching and tried pavucontrol which confirmed the doubts by showing Firefox output still going to analog stereo).

Sometimes, especially on intel platform, you need to configure the sound card to output HDMI audio instead of speakers/headphones. At least with pulseaudio (change sound card profile in pavucontrol's settings tab).

I wonder how your setup is different than mine. I also switched to Pipewire (some months ago) and I'm using NixOS and Arch Linux, and on both I could just change the audio output to my speakers on my monitors (via HDMI) with the usual device switch, same as before with just PulseAudio. Everything works perfectly.

https://github.com/Lillecarl/nixos/blob/1c76775bbed80057cf54... https://github.com/Lillecarl/nixos/blob/1c76775bbed80057cf54...

This is my pipewire config, does the job perfectly for me, tracking unstable.

Off topic, but I watched the ffmpeg args that go-chromecast used and scripted it. Now I preproces my videos and use catt.

You can detect when they're h264 and use - c:v copy for speediness.

I must admit I simply didn't realize the pulseaudio commands would still work. I figured they wouldn't because they were no longer installed after disabling pulseaudio and switching to pipewire. That's why I was trying to make things work with the pw-* commands and failing.

Have you tried different profiles for your hardware?

Assuming you're talking about Bluetooth mics: If you're using pipewire-media-session (for example, if you're on NixOS 21.11 instead of NixOS unstable), then profile autoswitching [0] is disabled by default, so you have to use pavucontrol to switch from A2DP to HSP. Profile autoswitching is enabled by default in WirePlumber, which is the default session manager in NixOS unstable as of a few days ago.

[0] https://wiki.archlinux.org/title/PipeWire#Automatic_profile_...

Wait what. I've desperately been waiting for this feature and now I learn it's already been there for a while (albeit disabled by default). ._.

(Kinda goes to show that enabling this feature by default is a good idea.)

Thanks, you just made my day!

For the command-line folk:

  # mic on, worse audio quality
  pactl set-card-profile bluez_card.DE_AD_BE_EF_FA_CE headset-head-unit

  # mic off, better audio quality
  pactl set-card-profile bluez_card.DE_AD_BE_EF_FA_CE a2dp-sink

Can anyone explain me like I'm five, why this major transition from PulseAudio to PipeWire is happening during the last year?

because it's very easy to use and works good

Pipewire was started by Wim Taymans, one of the gstreamer people. Originally it was supposed to allow video-streams in sandboxed environments like flatpak (and was known as "pulsevideo"), but then he noticed that it could be extended to do audio as well.

Since pulseaudio's architecture isn't well-suited to incorporate sandboxing, that project continued and it turned out that it could handle compatibility with both pulseaudio (the sound server for "consumerist" needs) and jack (the one for "pro audio" people where low latency is paramount).

You can even use programs like QJackCtl, which was written for Jack, to perform audio routing and stuff with pipewire!

So now, we have a sound server that

1. is much nicer to configure than pulseaudio

2. is compatible with sandboxing

3. is compatible with pulseaudio, jack and the older alsa APIs and features

4. is developed much more quickly than either of the others

5. Pipewire doesn't use buffer rewinding, which was a rich source of complexity and bugs not only in PulseAudio, but also exposed bugs in the kernel audio device drivers. And even bugs or poorly specified behavior in HW itself, considering AFAIU neither macOS, Windows (nor Jack) use rewinding.

The PA docs claim that buffer rewinding is used to achieve low-latency updates to a high-latency stream. E.g., user wants to change volume now on some music that has a 2 second buffer. Seems like a common use case.

How does Pipewire deal with this?

Also-- links to the audio driver bug reports, please!

Also-- links to info on the hardware bugs, please!

I believe you, I just want to read about them.

>How does Pipewire deal with this?

It doesn't, it sets a much shorter max buffer length so that the latency is always acceptable. This does mean that in theory, with an otherwise totally idle system, PipeWire can't be quite as low power as PA.

So if Windows/MacOS/Jack all lack support for buffer rewinding without noticeable latency, does that imply that Pulse encourages the use of abnormally large buffers compared to what all other audio systems use?

Wim Taymans is amazing. Maybe one of the greatest programmers of all time.

> 2. is compatible with sandboxing

"DOC,ENH: How to connect container pipewire, alsa, jack to host pipewire (#1612)" https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/16...

Thank you! So is pipewire a replacement/superset of gstreamer? Or is it supposed to be a higher-level component (more user facing than gstreamer). Alternatively, is Pipewire about connecting audio devices (instruments, speakers) to software on the computer?

> So is pipewire a replacement/superset of gstreamer?

It is neither. Gstreamer deals with codecs and such. It's a set of libraries that an application uses to handle multimedia needs.

Pipewire is a service that handles streams and passes them off to hardware.

If you wrote e.g. a music player, you could tell gstreamer to play a .mp3 file, and it would decode it (by using its mp3 codec) and send the audio off to the pipewire socket, and pipewire would send it to the hardware to actually, you know, play. Pipewire would handle buffering and resampling and mixing and all that fun stuff.

Pipewire sits at the same level in the stack where pulseaudio sat before, and gstreamer also talked to that (and in fact you can speak to pipewire as if it was pulseaudio).

It's simply that it was written by a person also involved with gstreamer.

Originally gstreamer was going to be used, but in something a bit smaller and less general was needed.

(Gstreamer is fantastic as a swiss army knife, but something a bit more focused is needed).

I believe this will interface with gstreamer just fine though.

Pipewire has become more usable for audio during the last year.

Actual advantages of pipewire vs pulseaudio are not that obvious, but it should mostly be lower-latency, hopefully more stable, and more flexible (provide something like the old `jack` API where any stream can be plugged anywhere). Also, support for sandboxing (flatpak portals) is first-class, as one of the early design goals was to provide this for video.

Pipewire is also used in most places where wayland is, to provide screen sharing capabilities (now, if proprietary software could catch up... looking at zoom).

And lastly, pipewire should hopefully become one of the best APIs for accessing webcams and other video streaming devices in the future (allowing stuff like sharing a camera between multiple apps, simple sandboxing, middleware for compositing or video effects -- think background removal tools). Support is a bit sparse for now, but there's a LD_PRELOAD workaround for v4l2 interfaces.

Edit: also, pipewire gained support for nicer bluetooth codecs faster than pulseaudio did.

> Edit: also, pipewire gained support for nicer bluetooth codecs faster than pulseaudio did.

Yep, I have a pair of Sony WH-1000XM3 which supports better codecs like LDAC and you had to resort to a 3rd party, home-made repository in Ubuntu for pulseaudio (initially there were licensing reasons but then Sony opensourced it IIRC). With PipeWire (on Ubuntu 21.10) I just have to install a package from the standard repo.

There are some things PipeWire makes a lot easier to do.

For example, I have an electric piano that I can connect to my computer and play. I had to install a special software called "jack", because PulseAudio would have me wait before I could hear a note I played.

Jack was not simple to use, but even if you were good at it, there were problems. Imagine you wanted to play along with some music. Well, bad luck, some software do not support jack, and you can't use it together with PulseAudio.

Now lets say I want to stream my playing on Twitch. Again I will have trouble, because the many moving parts in streaming, including video, make it very difficult to output a high quality stream.

Last, when I use DaVinci Resolve to edit and upload my stream to Youtube, I want to record some voice over. Resolve has this function called "ADR", or "Automated dialogue replacement" -- it's a feature they use in film to record the actors on the computer. I could use that to record my voice over, but ADR on Resolve doesn't bother with either Pulse or Jack, and uses something called "ALSA". That means that until Resolve finishes using it, I can't use my microphone!

With Pipewire I just click and it works.

> and you can't use it together with PulseAudio

You absolutely can, PA is then present in JACK (and JACK in PA) as a single sink/source that you can route like any other app - so not as flexible as PipeWire, but not as problematic as you paint it either.

Yeah, but in practice I never managed to get that work consistently.

Works really well for me for jamming with Jamulus ;)

Same

I think the main reason for the sudden uptick in Pipewire usage is that due to the pandemic a lot more people were doing daily video meetings with screen sharing. And for all people that have migrated to Wayland, this was a major source of pain.

With pipewire, this works quite nicely, including for applications that are sandboxed (e.g. Jitsi in a Flatpak). In my bubble, when people talked about using Pipewire, it was almost exclusively related to screensharing on Wayland.

I've switched from Pulseaudio to Pulseaudio-on-Pipewire last year and haven't looked back. Next step would be trying to set an audio processing pipeline with audio effects (like a multiband equalizer tuned to my headphones), something that I managed to set up with Jack before using Pipewire, but that was always a pain.

Some more anecdata, I switched to pipewire when I bought my new laptop and it was great. I was struggling to get pulseaudio working properly, switched to pipewire and installed pipewire-pulse[0] from the arch packages, and stuff "just worked".

It's one of the only times in recent memory that moving over to 'the new thing' actually worked without significant pain.

https://archlinux.org/packages/extra/x86_64/pipewire-pulse/

I actually did have a few issues and things to tweak when I switched (I think I did it fairly early) but after some initial setup everything started working perfectly.

> WirePlumber was made the default PipeWire session manager in Fedora 35

That sounds great and all, but can someone enlighten me exactly what a session-manager is, in the context of Pipewire?

I’m using Pipewire and it works fine. But is this something I should know about? Something I can or should tweak? Or is it mainly for the distro-maintainers?

Most pipewire users here seem to be arch users with access to bleeding edge releases.

But how does PW work for, say, Debian/Ubuntu users?

Debian unstable user here (and also Gentoo on a different PC) - I've removed PulseAudio for a couple of months now, and everything works nicely (including a Bluetooth headset and HDMI audio out) with PipeWire and WirePlumber - the only hiccup was an old manual configuration I had for ALSA to use PulseAudio as default audio sink, which needed to be removed.

I haven't tested Jack compatibility yet.

Works great on debian bookworm as a full replacement for jack and pulseaudio.

Read the debian wiki for the setup.

I use it together with wireplumber on three systems, all running bookworm. One old MacBook Air, a fairly new ThinkPad and a run-of-the-mill desktop PC. Works flawlessly on all of them. I have no custom configuration, all default what comes from the packages.

For the laptops I also use BT headphones, and with the ThinkPad I use a headset that with the latest wireplumber switching profiles just work whenever I join a meeting with Slack or Teams (both in Google Chrome).

For the desktop PC I had a use case I never got working properly, or at least easily, with PA. That is to expose all the HDMI outputs of the graphics card as separate sinks. With PW, just switch over to the Pro profile and they all appear. Then I can route what ever stream/application I want to a specific HDMI output.

Additionally, I use USB MIDI devices and a software synth, qsynth, using JACK. Setting up both MIDI and audio routing via qjackctl is so convenient.

Oh, and USB audio devices also work without a problem. Can't say if that is different from PA as I never used them much before.

Debian Sid (aka Unstable) is just as bleeding edge as any other "rolling" distro.

Sid is a rolling unstable development build, that doesn't compare to a rolling stable release - particularly in regards to conversations on what users should expect.

"rolling stable" is an oxymoron. There cannot be such thing as rolling and stable at the same time.

There's a ppa which works fine with Ubuntu 20.04:

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

It's not a bleeding edge-only thing, Pipewire was first introduced in Fedora (because RedHat), it's been fairly well tested as far as OSS goes.

Fedora also uses PipeWire by default, since version 34, so for almost a year now.

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

Fedora 35 on a thinkpad, somehow pulseaudio&some new kernel version makes it so that my laptop refuses to return from suspend, until I plug it in to wall power.

I didn't have to investigate further, but there is one open bug from another user: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/13...

https://bugzilla.kernel.org/show_bug.cgi?id=214019

Otherwise pipewire has had some bugs with audio switching and firefox at the beginning, but the last month or so has been great.

Currently using pipewire on Ubuntu 21.10 via the ppa (which is linked in another comment here).

Experience has been flawless until now. Its truly an outstanding piece of software that "just works" and gets out of your way. I am really, really happy to use it, it has simplified so many things in my day to day life.

Before, using pulseaudio, connecting my bluetooth headset and getting any application to work with it was a serious pain, now it is a matter of turning the headset on and boom, connected, all audio switches automagically over to the headset.

I switched to PipeWire few months back on Manjaro and apart from a problem with packages when switching, there is one issue which bothers me slightly - Bluetooth headphones delay. I tried all codecs on my QC35-II, 3 different BT 4 and 5 dongles and the delay is unbearable, rougly 500ms, kills CS:GO experience. On a headphone jack PipeWire is great, audio is clean without any glitches. Just this bluetooth...

No delay on Fedora 35 with all defaults

I've also experienced this on Arch Linux, in the form of a variable delay to my bluetooth speaker under pipewire but not pulseaudio. I also noticed a lot more general bluetooth flakiness. I have not characterized the issue nearly as thoroughly as you have. Instead I ran a wire to the other side of my office and installed some DIY speakers, which rendered the problem moot. Regardless, I've always had issues getting bluetooth to work reliably, especially on linux.

I'm using pipewire and pipewire-pulse in void linux, and everything works perfectly.

Do Bluetooth devices also work perfectly?

For me, BT works perfectly with PulseAudio. PipeWire is very satisfying for absolutely everything else, but BT devices just refuse to connect (and I'm inept at debugging BT issues).

For me, on several machines, the _only_ way I could get Bluetooth devices to connect, behave, and to use their high quality codecs was switching to PipeWire.

As it stands, between my desktop (Manjaro), laptop (NixOS/Ubuntu) and work laptop (Ubuntu 20.04), I have one single issue with Pipewire; on my work laptop if I have audio output set to HDMI (monitor speakers), when I plug in a wired headset to join a conference call it doesn't switch to the headset. If it's set to internal speakers first, it _does_ switch. So, if I have a conference call and I was using the monitor speakers, I have to jump into the Gnome sound control and switch to headset manually.

0 issues with PipeWire and Bluetooth audio in my experience. Try setting `bluetoothd` logs to debug and look a bit on what's happening.

I had problems until i realized i still had `pulseaudio-*` packages installed. Now I only have `pipewire` and `pipepire-pulse` and everything works flawlessly.

Thanks, that's a useful hint!

Agreed. I've recently migrated to Arch and pipewire/pipewire-pulse made the audio setup a breeze.

Can anyone link to some documentation explaining how to make it work without messing with other software? I tried twice to enable it on two different Debian installs, and both times I suddenly lost access to all my MIDI devices under Wine (no matter the user or the Wine version), although they were still perfectly usable by native Linux software, so I had to uninstall it back.

In my experience, switching to WirePlumber fixed the few problems I had originally had with the default session manager.

Wireplumber looks very capable to me, although I think the documentation could be better, especially there could be more examples for more advanced configuration.

One thing I still fight with is pw-loopback. I like to create a default sink that I can remap to my sound card. Playing a simple sine over that will give me hickups and dropouts. There is nothing in the documentation of pw-loopback that tells you any about this and as of now I could not resolve it.

When I plug the same output directly into the soundcard in Catia, the sound issues are gone.

I've switched to Pipewire. I couldn't A2DP working until I restarted, for some reason. Now everything runs OK.

Maybe you still had a pulse daemon running

That's possible.

I just wish PipeWire didn't have such choppy audio under load, pulseaudio doesn't have the same problem.

Yeah it's awesome, if only nomachine(https://www.nomachine.com/, MS Remote Desktop alternative) would add support for it, that or I missed something to get it to work.

I gave pipewire a go for a few hours tonight, but couldn't get the A2DP profiles to appear in pavucontrol. Bluetoothctl seems to happily connect and pair, but there's nowhere to point the output to my bluetooth headset :(

I might start to look into Linux again for DAW usage. I'm very much on Logic/MacOS and dip my toe every so often (well have done since Dynebolic days) but always go back to Logic.

2p; it would be nice to see native PW CV rather than JACK API CV, as well as some form of integration with NSM for saving graphs and making them portable.

I tried to get pipewire to work in Gentoo on my laptop. I was not successful. I do hope things will improve.

Still facing several bugs in pipewire/wireplumber on Alpine. Not entirely sure if I missed some configuration (it's a bit confusing) or just buggy, though I've def seen some other user reports with the same bugs as me. Probably going back to pulse to get working audio/bluetooth again.

Linux is a real trip, man. Bluetooth was introduced 24 years ago and we can still barely make it work. Seems to work on Windows, Android, Mac.

Never encountered a platform that didn't gave me problems with Bluetooth, honestly. Maybe on other platforms things are a little bit smoother but also with inferior troubleshooting.

Reply on news.ycombinator.com