March 05, 2020
PipeWire 0.3 was released a few days ago, marking a big step forward in the effort of making this emerging media service the core layer of all multimedia on Linux.
A huge effort is currently underway to bring the Linux desktop into the future with the help of containerization technologies such as Flatpak. One of the goals of this exercise is to create a clear security barrier separating the applications from each other and from the system. The media stack is one area where the applications normally fail to co-operate with this model, requiring direct access to the hardware because large amounts of data need to be exchanged and a low latency is often critical. PipeWire is the missing piece to this puzzle, allowing applications to access hardware devices in an efficient, yet secure manner.
PipeWire was originally created to only handle access to video resources and co-exist with PulseAudio. Earlier versions have already been shipping in Fedora for a while, allowing Flatpak applications to access video cameras and to implement screen sharing on Wayland. Eventually, PipeWire has ended up handling any kind of media, to the point of planning to completely replace PulseAudio in the future. The new 0.3 version is marked as a preview for audio support.
But why replace PulseAudio? Although PulseAudio already provides a working intermediate layer to access audio devices, PipeWire has to offer more features that PulseAudio was not designed to deliver, starting with a better security model, which allows isolation between applications and secure access from within containers.
Another interesting feature of PipeWire is that it unifies the two audio systems used on the desktop, JACK for low-latency professional audio and PulseAudio for normal desktop use-cases. PipeWire was designed to be able to accommodate both use cases, delivering very low latency, while at the same time not wasting CPU resources. This design also makes PipeWire a much more efficient solution than PulseAudio in general, making it a perfect fit for embedded use cases too.
Luckily, once PipeWire is stable enough to be the default audio service on Linux, audio applications will not need to be updated straight away because compatibility APIs for ALSA, PulseAudio and JACK are also included in the project, making the applications connect transparently to the PipeWire daemon without any code changes and even without recompiling. However, we expect that most applications will eventually be updated to use PipeWire’s native API to clean up their dependencies and to be able to use more advanced PipeWire features. Thankfully, applications that use GStreamer can easily switch to use the GStreamer elements that are also provided by PipeWire, making this port trivial.
Just like PulseAudio, PipeWire is a daemon that runs in the background and acts as an intermediate layer between multimedia applications (clients) and devices. This intermediate layer's main role is to connect these applications to the devices, allowing them to play or capture media, while respecting access permissions.
A key difference to PulseAudio is how PipeWire does session and policy management. While PulseAudio comes with its own predefined logic about which applications to connect to which device(s) and when, PipeWire itself does nothing about that. PipeWire only provides the means to create media streams, while the management logic is implemented in an external component, the session manager. Since this management logic is dependent on the platform and the use cases that this platform is dealing with, having an external session manager allows developers to more easily adapt PipeWire's behavior to any kind of situation.
At Collabora, as part of our work for Automotive Grade Linux, we have been developing an extensible session manager, WirePlumber. This has been necessary for integrating PipeWire into AGL, since PipeWire itself only ships with an example session manager that does not scale for anything other than simple desktop use cases. WirePlumber currently focuses on automotive and other embedded use cases, but we will soon be adding desktop support, making it possible to replace the example session manager for desktop testing. We will be blogging more about WirePlumber in the future, explaining the motivation for writing it, our design choices and further progress that we make in its development.
George Kiagiadakis presents "PipeWire in the Automotive Industry", recorded last month at FOSDEM 2020.
Last year, from June to September, I worked on the kernel development tool Coccinelle under Collabora. I implemented a performance boosting…
The open source Panfrost driver for Arm Mali Midgard and Bifrost GPUs now provides non-conformant OpenGL ES 3.0 on Bifrost and desktop OpenGL…
This year, the global pandemic has put a strain on us all. Motivation can become hard to maintain, worries can cloud our minds. Now more…
Wayland is still lacking proper consideration for color management & support for high dynamic range (HDR) imagery. However, a group of developers…
This week marks two years since the OpenGL implementation on Vulkan was initially announced. Since then, and especially over the past few…
Since our previous update on Panfrost, the open source stack for Arm's Mali Midgard and Bifrost GPUs, we've focused on taking our driver…