One clarification to TFA:

>And also we can have patchbay applications that supports video pipelines and not just audio, like Carla provides for Jack applications. To be clear this feature will not come for ‘free’ from Jack patchbays since Jack only does audio, but hopefully new PipeWire patchbays like Helvum can add video support.

There actually have been patches for JACK to enable it transport video just like it already handles audio & MIDI. We never accepted them into the mainstream.

The specific problem with video compared with audio is this: for audio, settling on 32 bit floating point as the canonical format for audio (and note, JACK did not prevent you from using other formats, even internally; people just didn't bother) was not even remotely controversial. Nothing is lost and much is gained via this choice.

For video, however, there are a plethora of possible format choices, each with their own distinct reasons for being, and often significant computational costs associated with conversion. This means that for video it's fairly problematic to define a single format for an entire workflow, which in turn means that figuring out when/where conversion between formats occurs is a significant task. For JACK, we decided not to try to do this, and left the system handling only audio & MIDI.

When F34 initially came out, PipeWire broke Bluetooth audio on my laptop. But a couple of days later, a patch came in and just fixed it without me having to do anything. Every couple of days, a new update for it drops and it just keeps getting better and more stable. This really seems like a good one-for-all solution for low-latency audio.

I really wish Zoom could start using PipeWire for their screen sharing and video as soon as possible. Currently their desktop app gives a very interesting error if trying to share the screen from Wayland/sway. There is no need to only support Gnome on Ubuntu et.al. with PipeWire.

The only way to use Zoom from my point of view is through their web app. And every time I start a meeting from their web interface, they're using every possible dark pattern to force me to install their official app.

Their app is really bad. The good news is that their screen sharing based on gnome's private screenshot API should stop working altogether as Gnome 41 is securing those APIs.

Their webapp is quite bad as well though and behind in features especially on Firefox on which, for whatever reason, there's no gallery mode.

They should drop their crap desktop app and focus on building a descent webapp instead.

The weird screenshot thing also leads to confusing issues like this one: https://github.com/flathub/us.zoom.Zoom/issues/223. Zoom tries to avoid sharing its own windows by using an X window property that specifies the owning PID, so it filters out any window where `_NET_WM_PID == Zoom's PID`. In a modern Linux desktop where applications are sandboxed, many different applications can think they have the same PID, so it ends up filtering out other applications.

Not sharing its own windows is nice and all, but I don't think Zoom even does that on other platforms. It's weird how much effort they have put in to doing the wrong thing.

Adding to this I also wish Zoom to use native Pipewire for desktop audio capture, currently Zoom desktop audio sharing doesn't work when pulseaudio is replaced by pipewire

Would obs be helpful here? I would think you could tell zoom about an obs virtual camera and use obs with pipewire for the capture.

Have you tried installing zoom as a flatpak from flathub?

Using it at Fedora Silverblue 34 (Gnome 40 on Wayland) and screen sharing works (using it often at work).

Zoom screen sharing on wayland has been hacked around Gnome's private d-bus screenshot api. It doesn't work in any other environment.

That's not really a big deal, you could just develop a small shim for that d-bus API if you really needed to. But I agree, it would be better for them to switch to Pipewire.

I don't suppose anyone has hints for switching to wired headset on Ubuntu "on-plug".

I switched to pipewire recently and the experience for Bluetooth is amazing.

On an average day I have audio output set to HDMI while I listen to Spotify and work; when I plug in a wired headset for a meeting the gnome switcher dialog pops up but when I select headset, it doesn't work since moving to pipewire, output remains with HDMI and input from the laptop internal mic. I have to go into Sound every time and manually switch to headset out and headset mic.

It doesn't seem to have this issue if I'm not using HDMI output.

There are only scripting solutions right now based on pacmd and acpi calls. My pinebook pro needs a hack like this as well for when I want to use my headset.

So putting a script /etc/acpi/ should do the trick, but is a bit hacky.

Interesting, good to know it's not just me.

I'll switch my work laptop back to pulseaudio as being able to switch on plug/unplug is critical for my average day.

My personal laptop can stay on pipewire since I exclusively use Bluetooth there.

Hopefully it's a feature that'll be implemented soon.

I had to read the blog on lynx due to light grey text on white. I wish people will realize many people will have a hard time with that coloured text.

Well a bit concerning in a way. Does this change require GNOME and/or Wayland ? The way I read it it seems so, but little detail there.

I wonder because I use fvwm2 as opposed to Desktops, which I really do not like at all.

> had to read the blog on lynx due to light grey text on white.

No need to go that far, this site supports reader mode.

> Does this change require GNOME and/or Wayland?

PipeWire is not bound to Wayland or a specific desktop environment, it runs (mostly) fine under GNOME, KDE Plasma as well as sway. The desktop interfacing is done via flatpaks xdg-desktop-portal, as long as your desktop implements that you should be fine.

I've heard so much nice things about this, but just can't figure out how to get it to work.

AUR has packages for replacing PA and jack with pipewire, but when I tired this I ended up with a dead ardour and not even timeshift could get me back to a working system.

I have the following packages:

    pipewire-alsa 1:0.3.38-1.1
    pipewire-jack 1:0.3.38-1.1
    pipewire-jack-dropin 3-2
    pipewire-media-session 1:0.3.38-1.1
    pipewire-pulse 1:0.3.38-1.1

As well as

    systemctl --user enable \
      pipewire.service \
      pipewire-media-session.service \
      pipewire-pulse.service

and everything works great. I really like that I can use qjackctl to route every audio app nowadays.

What do I need to remove to get this working without any conflicts?

You mentioned qjackctl, is there a reason I must keep using that instead of having everything defaulted to PW pipe

Everything uses PW pipe.

Pipewire implements the API of all the system it replaces. So you can keep using Jack routing tools while everything is actually using Pipewire.

Does `systemctl --user disable --now pulseaudio` help? Also you can use `enable --now` to enable and start at the same time.

Don't forget to mask pulseaudio, just disabling it isn't enough.

The difference seems to be:

disabled - the service is not started automatically

masked - the service can't be started at all, even explicitly requested by user or app

On Ubuntu at least, I had to mask it otherwise pulseaudio was started again on reboot despite being disabled.

pipewire (and pipewire-jack) has been in the main arch repo for a while now. if you're using an aur package, it probably has issues.

True, you can even choose pipewire with the archinstall installer and it runs great on my machine.

No need for the AUR. It’s in extra in the official repos.

See https://wiki.archlinux.org/title/PipeWire#Installation

I’ve had zero issues.

A reboot is often required to integrate the session changes.

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

Your session environment might also need to be aware of how to interact with PipeWire, which by default is via pulsaudio compatibility interfaces.

Required (practically, probably pulled in with just pipewire):

pipewire pipewire-media-session pipewire-pulse

Recommended:

pipewire-alsa pipewire-jack lib32-pipewire lib32-pipewire-jack

You might also need to reconfigure your audio settings, but that is unfortunately desktop session specific. (E.G. KDE has it in one place, gnome desktops another, etc)

> "A reboot is often required to integrate the session changes."

"To apply the changes you must restart your computer"

It is just sad.

Restarting your whole session is enough but you must restart every connections between the sound server and applications. Restarting is just often the easiest way to do that because it shutdowns everything and rebooting is extremely fast nowadays but it is not required.

You've always had to basically reboot your computer for big system component changes to be applied, otherwise you'll have some applications running the old system, and some running the new system. Yes, you could close those applications, but that's practically every process in your session, and getting the order right is tricky.

Both PulseAudio and PipeWire work best when running the underlying kernel drivers in "exclusive" mode, which means only one sound server can be running at a time. In order to ensure that works correctly, you need to:

1. Close all applications

2. Shut down PulseAudio and prevent it from auto-restarting

3. Start up PipeWire, and then restart your desktop environment if you want any hope of the volume applet working (or figure out which of the processes to kill if your volume applet in another process)

4. Start up your applications again.

5. There might be some applications that have tried to play audio that you were unaware of! Like your file manager, which can play a custom "bell" for mandatory audio alerts when trying to type in a place that doesn't accept characters. Oops! Better close that down too and start 1-4 over again.

Restarting the computer is an easy and safe way to apply these changes. That people didn't follow all these steps in this exact way meant the computer started to break in strange and unobvious ways, not that it was ever supported.

If you want to help out designing smoother ways to change out core system components without reboots, feel free to do that. The people involved might not find it worth the trouble to fix, though. I think it's just sensible to restart the system.

It's not necessary it's just easy to explain.

Now that it matched feature-wise the leading competitor, truly the year of the linux desktop is now!

If we're lucky, it will take them ages to polish this turd, so effectively you're still good "just" using pulse. Which also broke on my laptop after the last dist-upgrade, and after half an hour of debugging and fiddling I gave up. Found "apulse" which is a small library you can LD_PRELOAD that implements the pulse api but simply translates everything to ALSA. Doesn't support the more advanced stuff from pulse obviously, but works for normal things like Firefox etc.

> In fact in the first few releases of Fedora Workstation where we shipped PipeWire we solely enabled it as a tool to handle screen sharing for Wayland and Flatpaks.

PipeWire is truly a godsend for screen recording on Wayland, not very long ago, if at all, every desktop environment / compositor had their own home brewed protocol and developing anything related to screen recording on Wayland was a massive pain [1]. I still can not fathom how Wayland could even exist this long without any decent way to do screen recording and I also do not get why there is no official protocol or at least extension for this!

But thanks to PipeWire some first projects finally support screen capturing on Wayland. Both Firefox (via webrtc) [2] and OBS [3] directly interface with PipeWire. For my personal project Weylus [4] I opted for the gstreamer plugin as at the time the documentation for PipeWire itself was very lacking and I could not figure out how to get it to work. Fortunately gstreamer is better documented and it turned out to be rather easy to use. But it shows that all this is still in an early stage as I hit quite some bugs, probably the most egregious (maybe even somewhat funny) one is KDE's kwin_wayland crashing if you hover the cursor over any window close button while screen recording [5], sadly it doesn't seem to be fixed yet. For some more bugs I've hit, see [6].

Something I am a little worried about is that flatpak with their xdg-desktop-portal [7] is now responsible for the de facto standard how screen recording is negotiated on Wayland. I fear that this means if flatpak does not need a feature, even if it makes sense in another context, it probably won't ever be implemented. For example something I require for my project are proper window names and their position as well as size, but apparently this is nothing essential for flatpak and the issues I have opened have largely been ignored [8]. This is by no means meant as an accusation, just an observations that things are not all good.

[1]: https://github.com/H-M-H/Weylus/issues/3#issuecomment-652670...

[2]: https://webrtc.googlesource.com/src/+/refs/heads/main/module...

[3]: https://github.com/obsproject/obs-studio/blob/master/plugins...

[4]: https://github.com/H-M-H/Weylus

[5]: https://bugs.kde.org/show_bug.cgi?id=435042

[6]: https://github.com/H-M-H/Weylus/issues/3#issuecomment-808940...

[7]: https://github.com/flatpak/xdg-desktop-portal

[8]: https://github.com/flatpak/xdg-desktop-portal/issues/created...

>I still can not fathom how Wayland could even exist this long without any decent way to do screen recording and I also do not get why there is no official protocol or at least extension for this!

It likely won't ever get an official Wayland extension, for a number of reasons. Screen capturing is inherently insecure and so it shouldn't really be happening over the Wayland socket. It also doesn't need to happen over the Wayland socket or be related to the windowing protocol at all, attempting to do it that way is just re-accumulating technical debt left over from X11.

>I fear that this means if flatpak does not need a feature, even if it makes sense in another context, it probably won't ever be implemented.

I wouldn't think of it so much as just flatpak, but the API needs to be usable from within a sandbox, and it needs to be done in such a way that it can be reasonably presented to the user.

>For example something I require for my project are proper window names and their position

This is a really bad idea, don't do this. This is guaranteed to mess with the window manager and run into any number of syncing issues with window sizes being reported incorrectly. It's also a misuse of the screencasting API. I checked the issues you posted and I don't think you're going to get much farther trying to hack around the API. If you want to do this right now then you'll have to integrate with the specifics of the window manager or shell. There is no way around it, I really doubt you will get much interest in doing it another way.

> attempting to do it that way is just re-accumulating technical debt left over from X11

I see, I do not know much about the internal workings of Wayland. The problem I do see though is that screen recording is an essential feature that has been neglected for years due to the lack of a standard.

> This is a really bad idea, don't do this.

While I agree that getting window positions may be questionable, providing a human readable title for the streams that have been selected seems obvious, yet is missing.

> syncing issues with window sizes being reported incorrectly

This seems rather theoretical to me, while of course true, I doubt it is going to matter in practice.

> It's also a misuse of the screencasting API.

Hmm, do you think there is a better solution, that isn't giving up and having each desktop environment do its own thing?

> If you want to do this right now then you'll have to integrate with the specifics of the window manager or shell. There is no way around it, I really doubt you will get much interest in doing it another way.

This is also my conclusion, alas it's not happening and one of the reasons why I think Wayland is not quite there yet.

There is a standard API for screencasting and it works fine if you're only doing screencasting. Since the API is in the xdg portal, it sits at a layer above Wayland and X11 and in theory it should make it easier for you because it works the same on both of them and you could avoid writing window system specific code and just have one Linux backend using the xdg portal. But in practice it seems like your use case needed to access window system specific functionality anyway.

In my opinion, what you're asking for is an entirely new thing. You want an API for window management, but there has never really been a window management API on Linux, and every desktop environment was already doing its own thing. It has nothing to do with Wayland specifically. Under Xorg, the X11 APIs can sort of be hacked to do what you're asking under certain circumstances, and it might work ok on some window managers, but it's not going to work in every case. (And it doesn't play nicely with sandboxes either)

To get the human readable title seems like it would be an issue with how Mutter publishes the stream, i.e. not an issue with the portal itself. But I haven't looked into this enough in detail. I also don't know enough about your application to know why you would need the window sizes and positions. My only point is that if you intend to use that to draw an overlay over a screencast, or otherwise try to reconstruct what the compositing process is doing, then that's not going to be completely accurate. And it can't really be accurate without exposing various internals of how the compositor works, which puts any proposed API design back to square one...