Julian Bouzas
March 05, 2020
Reading time:
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.
19/12/2024
In the world of deep learning optimization, two powerful tools stand out: torch.compile, PyTorch’s just-in-time (JIT) compiler, and NVIDIA’s…
08/10/2024
Having multiple developers work on pre-merge testing distributes the process and ensures that every contribution is rigorously tested before…
15/08/2024
After rigorous debugging, a new unit testing framework was added to the backend compiler for NVK. This is a walkthrough of the steps taken…
01/08/2024
We're reflecting on the steps taken as we continually seek to improve Linux kernel integration. This will include more detail about the…
27/06/2024
With each board running a mainline-first Linux software stack and tested in a CI loop with the LAVA test framework, the Farm showcased Collabora's…
26/06/2024
WirePlumber 0.5 arrived recently with many new and essential features including the Smart Filter Policy, enabling audio filters to automatically…
Comments (1)
dirk ouellette:
Sep 21, 2020 at 10:08 PM
As a musician running kubuntu with kxstudio, I am excited and await further developements with Pipewire and derivatives.
Reply to this comment
Reply to this comment
Add a Comment