I’ve seen many sources praising Pipewire as a future de facto standard.
But just reading from the https://pipewire.org/ homepage I see that their heavy focus is Flatpak support and introduction of a security model that makes interacting with audio and video devices from containerized Flatpak applications easy.
I haven’t found anything on Pipewire developing the same for snaps tho.
Does that mean Snappy and by extension Ubuntu is being left out of that tech?
Does anyone have more knowledge on this topic? Is anyone from snap team working on Pipewire support maybe and what the future of this looks like to more initiated?
AFAIK we have received zero requests for snapd to support this.
If and when it takes off, I’d expect support to be easy to add. Or at least straightforward.
Pipewire focusing on flatpak first is natural, as they’re both redhat projects.
That answers my question. Thanks!
That’s not quite the truth for why, though. Flatpak doesn’t have generic interfaces for multimedia, and Pipewire provides those facilities. Even more so, Pipewire was conceived for unifying the multimedia pipeline and supporting certain types of multimedia in Wayland. It is already required in GNOME for certain things, and some applications (like Zoom) require it for screen sharing in Linux on Wayland.
I think we will want to support Pipewire in future: It seems likely that it will supplant Pulse Audio as the default sound server for Linux desktops, and will probably be the primary screen recording solution (i.e. streaming and remote desktop) for GNOME 3 as people move to Wayland.
As for Pipewire’s support for Flatpak, it is mostly confined to this module:
It is basically doing the following:
- check whether the client is sandboxed (currently by checking for the presence of
/.flatpak-info in the client process’s mount namespace).
- for sandboxed processes, call
org.freedesktop.portal.Device.AccessDevice(client_pid) on xdg-desktop-portal, which will make a decision about whether that application should have access. This will typically involve a permission dialog on first run.
Now (2) should already be functional for snap applications with a recent enough xdg-desktop-portal (e.g. 1.0). With a small change to the check in (1) so it can recognise snap confinement, this module would now handle both flatpaks and snaps. Alternatively, a second snap module could be written, but it would likely be about 90% identical.
On the snapd side, I think it’d make sense to grant access to Pipewire via the
desktop interface once the security module has been updated.