As part of the activities Embedded Recipes in May in Nice, France, Collabora hosted a dedicated PipeWire workshop/hackfest, an opportunity for attendees to meet face-to-face with PipeWire developers and participate in direct discussions about the future of PipeWire.

With PipeWire evolving at a rapid pace, the day's agenda featured several key discussion topics. Here's a look at what was covered, including updates on video transport, Rust efforts, TSN networking, and Bluetooth support.

Video status update

We started the day with Wim Taymans sharing his updates on video transport within PipeWire. His idea is to eventually build a system that allows routing video just like audio, with automated conversion to/from a common "DSP" format. Having already written a video converter that uses FFmpeg to convert between various video formats and with a Vulkan-based converter also available, the next step is to improve the format negotiation. Unfortunately, this is easier said than done, because some applications (like Firefox) seem to have very strange format requirements and expectations.

Among many things that were said during this discussion, one thing that came to become very clear is the fact that we need to build good video-related policies in WirePlumber. Being the session manager, it needs to be able to configure video nodes to use the "videoadapter" plugin for transparent format conversion, but also configure the most appropriate video conversion mode based on the use case. In audio, we get away with just converting everything to/from a common format (F32P, i.e. flating-point 32-bit plannar audio), which allows us to route anything to anything. While this is surely possible with video as well (to/from RGBA or something similar), it is not always the best because converting video is computationally expensive and that means we may be wasting significant CPU & power resources for use cases that don't need it.

Rust efforts

Moving on, after the morning break we talked about using Rust in PipeWire. Arun Raghavan shared his updates on the new Rust-based re-implementation of SPA and libpipewire. Unlike the previous pipewire-rs effort, which implements bindings on top of the native C API, Arun's new library re-implements the PipeWire protocol in Rust, with its goal being to enable Rust clients to talk to the PipeWire daemon over the socket natively, without calling into C libraries. Another goal of this effort is to expose SPA interfaces natively and allow dynamically loading SPA plugins, or implementing them, in Rust. When this is more mature, we should be able to mix and match PipeWire components written in C and Rust and use them together.

I am particularly interested in this effort myself, as I think that Rust will help the project not only to achieve having more functionality and stability with less code, but also to attract more contributors in the longer term. It is clear to me that Rust is the language of the future when it comes to systems programming and I believe that sticking to C will make the project less and less interesting to contribute to, for younger engineers.

TSN Networking

Leaving Rust aside, we continued with a discussion on Time-Sensitive Networking (TSN) in PipeWire, led by Oleksij Rempel. Oleksij brought into our attention some issues with the current code that uses `/dev/ptp` as a clock source. Apparently, the way that the kernel drivers implement clock primitives such as clock_gettime() on PTP devices is expensive in terms of time (!) and that means that when PipeWire calls into that to obtain the current time, it does not get as accurate results as one would hope from a PTP device. The correct way to do this is to always use the system clock and have some external daemon do a synchronization between the PTP source and the system clock, using proven synchronization techniques.

PipeWire issues

After lunch, we dived into a presentation by Martin Geier, outlining various issues that he and his colleagues have been seeing over time in both PipeWire and WirePlumber. It was interesting to listen to this as feedback and indeed Martin made some good points about specific areas in the codebase that need more attention and improvement. One good example is that WirePlumber's no-dsp policy appears to not be working with the latest versions and admittedly it is something that barely ever gets tested because it is not of any concern to desktop users. Another example is the weirdness of channel mapping in module-loopback, which may have a different internal channel count than what its input and output nodes have, forcing it to downmix & upmix without reason.

Streams on nodes

Shortly after Martin's presentation, we had a brief discussion on the status of the work that Wim had started a while ago to expose multiple streams on nodes. The idea behind this is to allow each node to have multiple groups of ports that correspond to different audio streams. At the moment, the ports that we see only correspond to different channels of the same stream. Apparently, Wim has a branch that makes this work, but the big part missing here is support for it in WirePlumber.

GStreamer elements

And after a short break, we were back to Arun Raghavan sharing his updates on the work that he and his colleagues did recently on PipeWire's GStreamer elements. According to Arun, the integration with GStreamer is in a much better state nowadays. Even though he was tempted to split the elements into video and audio specific ones, he eventually kept the original elements that can handle both audio and video depending on where they are linked.

Discussing video handling a bit deeper here, a solid outcome of the discussion was that we need to properly document how these elements may be used in this context and manage expectations. While people may be tempted to use them casually as a generic inter-process video transport mechanism, the reality is that there are strict rules on how this may work to avoid stalling the graph and/or have video memory overwritten in the middle of processing it!

Bluetooth

Before ending the day, we also talked about Bluetooth and looked at how to improve the codebase layout and quality to make it more maintainable in the future. A few recommendations came up, but since we didn't exactly have the relevant people attending the meeting, this discussion ended relatively quickly. If you would like to learn more about Bluetooth and PipeWire, I presented a talk at Embedded Recipes 2025, where I discussed recent developments and the current status of PipeWire’s support for Bluetooth audio features, as well as what we may expect to see in the near future. You can watch the recording here.

Permissions

Last but not least, I brought up the subject of enforcing permissions on objects for more generic desktop setups, without necessarily relying on Flatpak or similar mechanisms. At the moment, we only use permissions to restrict Flatpak camera and screen capture applications, preventing them from accessing other resources. However, we never do anything like that for audio and even though we have the mechanisms in place to implement this, even without the use of Flatpak portals, we don't do it. The need is present, however, with our customers often asking to take advantage of those mechanisms, while there is no clear plan for it upstream.

Through this discussion we came up with a bunch of ideas on what a permissions policy could look like, starting by defining roles for applications and classifying other objects depending on their use. An immediate goal would be to support the existing use cases of hiding either device nodes or filter nodes on some setups, extending it gradually for privacy use cases such as accessing the microphone only when the user has allowed it.

What's next?

Without a doubt, this PipeWire workshop proved to be a great success. Discussions were productive, and we all walked away with our heads full of ideas and our hands full of tasks. Being part of Embedded Recipes also gave us a great opportunity to reconnect with the GStreamer community (who also held their Spring Hackfest in Nice), something we hope to do again in the near future.

Work on PIpeWire continues at a rapid pace, with the latest bugfix release 1.4.6 being made available just before the weekend. If you would like to contribute to the project, or have suggestions to make or issues to report, please let us know in the GitLab issue tracker. You can also drop by the PipeWire discussion channels (matrix: #pipewire:matrix.org / oftc irc: #pipewire) to join the conversation.