We're hiring!
*

PipeWire: A year in review & a look ahead

George Kiagiadakis avatar

George Kiagiadakis
March 08, 2022

Share this post:

The PipeWire project has made major strides over the past few years, bringing shiny new features, and paving the way for new possibilities in the Linux multimedia scene. With 2021 seeing significant progress made on all fronts, let's take a moment to look back at what was accomplished, and what lies ahead for 2022.

Last year began with busywork on the Bluetooth® front, with amazing volunteers testing and fixing things on PipeWire's Bluetooth® plugin. Throughout the year, the plugin evolved to become perhaps one of the best - if not the best - open source Bluetooth® audio stack implementations that I am aware of. Based on an extensible plugin architecture, Pipewire already supports all current audio profiles and codecs. It is also future proof, enabling it to be integrated with other stacks like ofono. It's a solid base for any Bluetooth® audio use case.

Then, in April, Fedora 34 became the first Linux distribution to ship PipeWire as its default audio service. While PipeWire was there before as a video transport service to enable screen sharing on Wayland, the addition of the audio layer by default exposed all of PipeWire's incredible capabilities to a broader audience. This led to a significant number of improvements that were made to fix issues and improve the experience of several users.

In the meantime, at Collabora, we have been tirelessly working on getting WirePlumber ready to become the default session manager for PipeWire. With the 0.4.0 release that came out in June, WirePlumber introduced all those needed elements to achieve this goal. First and foremost, its Lua scripting engine made it possible to write most of the session management logic in a relatively simple scripting language. With the scripting engine available, it became so much easier for us to then sync all the policy logic with pipewire-media-session in order to replace PulseAudio. It also allowed us to maintain the embedded policy that Automotive Grade Linux uses with much more ease.

In September, we also integrated audio passthrough functionality in PipeWire. This was accompanied by the respective management logic in WirePlumber and pipewire-media-session to keep everything in sync. That has enabled faster audio paths for resource-intensive applications like video games as well as applications on embedded devices, avoiding the need for audio conversions that typically happen in a standard PipeWire audio setup.

Finally, after some intense bug fixing in October, WirePlumber was made the default PipeWire session manager in Fedora 35. It was shortly followed by other major Linux distributions that had started to use PipeWire for audio in the meantime.

Now in 2022, we are looking to the future. We already have designs to improve WirePlumber and experiment with new things. On the short-term horizon, we have plans to rework some parts of WirePlumber in order to make its configuration more user-friendly and the scripts easier to work with. We are also planning to revisit the policy logic and try to go a step beyond what PulseAudio has ever offered. In addition, we are looking forward to experimenting with complex cameras to improve how PipeWire and libcamera work together for an optimal user experience. We aim to lead the way for interesting new camera developments in PipeWire.

Here's hoping this year will be more amazing than the last!

Comments (12)

    1. George Kiagiadakis:
      Mar 09, 2022 at 03:47 PM

      I'm sorry to hear that, I was not aware of this specific issue.

      Just to clarify the statement in the blog post, our work here at Collabora has been mostly focused on PCM (raw, non-encoded audio) passthrough, which is to avoid converting audio to the standard float 32-bit planar format that is in use by PipeWire and to avoid resampling as well (if possible). Additionally, we worked on the session management logic around both raw and encoded passthrough and tested it with PCM and AC3 audio files.

      Reply to this comment

      Reply to this comment

      1. Be:
        Mar 09, 2022 at 05:35 PM

        Could you elaborate on the use cases for PCM passthrough? All I can think of would be passing through from an audio interface's input to output when the hardware lacks direct monitoring. Though I'm unclear why converting to/from 32 bit floats would be a problem.

        Reply to this comment

        Reply to this comment

        1. George Kiagiadakis:
          Mar 10, 2022 at 02:31 PM

          The use case for PCM passthrough is to reduce the load for resource-intensive applications on mobile devices, where every CPU cycle counts, both for performance and battery life. It is not a huge improvement and not something that I'd recommend anybody to use on a standard desktop system, but for a mobile device it counts. Mixing is still allowed in this setup, so you get the benefit of a sound server without the overhead of converting everything to float.

          Reply to this comment

          Reply to this comment

  1. Matthias Urlichs:
    Mar 09, 2022 at 05:20 PM

    Suppose I need to get a new Bluetooth protocol for Pipewire implemented. In my case: ASHA, i.e. audio to hearing aids over Bluetooth BLE. Suppose also I'm willing to pay somebody for doing that.

    Where do I ask?

    Reply to this comment

    Reply to this comment

    1. Mark Filion:
      Mar 09, 2022 at 05:37 PM

      We would be happy to look into this for you! Please get in touch with us at contact@collabora.com so we can discuss further.

      Reply to this comment

      Reply to this comment

  2. Be:
    Mar 09, 2022 at 05:33 PM

    "We are also planning to revisit the policy logic and try to go a step beyond what PulseAudio has ever offered."

    Could you elaborate on these plans?

    Reply to this comment

    Reply to this comment

    1. George Kiagiadakis:
      Mar 10, 2022 at 04:19 PM

      Glad that you ask!

      It's all just ideas in my head right now and no definitive action plan, but here are a few:

      1. It occurred to me that an interesting idea to explore would be to have some sort of namespaces for the objects, where clients in different namespaces would be able to see a different set of objects, including a different set of metadata (so, the "default sink" could be different in each namespace). We could then build things like effects pipelines more easily utilizing the different namespaces: in the namespace where actual playback apps run, there would be only one virtual sink (marked as the "default" sink) and no indication of the effects pipeline. Then, in another namespace there would be the effects nodes and the actual device sinks, with the default sink being the output device. This could simplify policy decisions, simplify the way that external programs like EasyEffects are built and avoid stupid bugs like https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/192 . Additionally, it could also open the way for being able to run a system-wide instance of PipeWire and share it with multiple users, with different user sessions running on different namespaces.

      2. When it comes to selecting and remembering default sources and sinks, there are a couple of issues currently. Sometimes it's not enough to just store the user's last selection and restore it later (there may be multiple preferences). It is also a bit controversial whether we should automatically switch to newly plugged devices, like headsets or HDMI monitors. In the case of headsets, people most likely expect the switch to happen. In the case of monitors, not all people expect it (because some do use the monitor's speakers, but others just use the display). My idea to solve these issues right now would be to add a number of options that would affect the selection process, allowing users to fine-tune the behaviour. This goes together with the plan to add configuration options that can change at runtime, via metadata, so we could later on build a GUI for tweaking all of that at runtime.

      3. Just like we store target sources/sinks for each application's stream (which can be changed via pavucontrol), I would also like to store static routing for pro-audio (JACK) applications and apply it when the relevant ports appear on the graph. Just like qjackctl and other JACK session managers work, but built-in directly in WirePlumber. I would also like to be able to mix the two worlds and say configure a native PA application to link to specific JACK app's ports without the need of a virtual sink and things like that...

      Reply to this comment

      Reply to this comment

  3. Lucas Camargo:
    Mar 10, 2022 at 12:50 AM

    Where can I get into the details of pipewire development? What's going to change in policy logic for example. Mailing list?

    Reply to this comment

    Reply to this comment

    1. George Kiagiadakis:
      Mar 10, 2022 at 04:22 PM

      There is a mailing list but we barely ever use it. The best way to stay in touch is to join the IRC / Matrix chat channel. See https://pipewire.pages.freedesktop.org/wireplumber/community.html for more details.

      Reply to this comment

      Reply to this comment

  4. Thomas Eitzenberger:
    Apr 20, 2022 at 09:20 AM

    Thanx for the update and the excellent work. Is there anything in the queue regarding DLNA support? Just asking for a friend that has some Bose speakers in his home ;) Didn't find anything on the net and a simple trial to use pulseaudio-dlna plugin with pipewire failed

    br Thomas

    Reply to this comment

    Reply to this comment

    1. George Kiagiadakis:
      Apr 20, 2022 at 03:29 PM

      Hi,

      DLNA would be a nice addition to the features list, but there is no immediate plan to add support for it. Pulseaudio-DLNA doesn't seem to work because it depends on some D-Bus API exposed by PulseAudio, but I believe it could be written in a different way to use the native protocol instead, and then it should work.

      Reply to this comment

      Reply to this comment


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

Adding secondary command buffers to PanVk

15/06/2022

Getting PanVk, an open source driver for Arm Mali Midgard and Bifrost GPUs, closer to conformancy by implementing one of the core Vulkan…

Bridging the synchronization gap on Linux

09/06/2022

After fighting with the divide between implicit and explicit synchronization with Vulkan on Linux for over seven years, we may finally have…

Monado's hand tracking: hand-waving our way towards a first attempt

31/05/2022

Optical hand tracking for XR has a bit of a reputation - getting training data, training neural nets, and deploying them in real-time, low-latency…

Visual-inertial tracking for Monado

05/04/2022

Monado now has initial support for 6DoF ("inside-out") tracking for devices with cameras and an IMU! Three free and open source SLAM/VIO…

Spotlight on Meson's full-featured developer environment

30/03/2022

When developing an application or a library, it is very common to want to run it without installing it, or to install it into a custom prefix…

How to write a Vulkan driver in 2022

23/03/2022

An incredible amount has changed in Mesa and in the Vulkan ecosystems since we wrote the first Vulkan driver in Mesa for Intel hardware…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2022. All rights reserved. Privacy Notice. Sitemap.