George Kiagiadakis
March 08, 2022
Share this post:
Reading time:
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!
14/03/2024
In continuation with our series about Kernel Integration we'll go into more detail about how regression detection, processing, and tracking…
21/02/2024
Now included in our Debian images & available via our GitLab, you can build a complete, working BL31 (Boot Loader stage 3.1), and replace…
19/02/2024
Back in 2022, after a series of issues were found in its design, I made the call to rework some of WirePlumber's fundamentals in order to…
08/02/2024
Continuing our Kernel Integration series, we're excited to introduce DRM-CI, a groundbreaking solution that enables developers to test their…
23/01/2024
This is the fourth and final part in a series on persian-rug, a Rust crate for interconnected objects. We've touched on the two big limitations:…
16/01/2024
One of the key high-level challenges of building Mesa drivers these days is figuring out how to best share code between a Vulkan driver…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (12)
Matt:
Mar 09, 2022 at 09:12 AM
Last I checked EAC3 passthrough is completely borked
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1648
Reply to this comment
Reply to this comment
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
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
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
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
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
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
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
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
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
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
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