Fedora Workstation 35 introduced a new session manager to PipeWire called WirePlumber. So what does a PipeWire session manager do and what makes WirePlumber special? To answer that question we talk to George Kiagiadakis. George is the main author of WirePlumber and can tell us what exciting things will be possible going forward with WirePlumber in place as the new official PipeWire session manager.
Christian Schaller: Hi George, thank you for taking the time to talk to us. Could you maybe start by telling us a little about yourself and how you got started with open source?
George Kiagiadakis: Hello Christian, thank you for having me in this interview. What can I say about myself… I am a senior software engineer, working at Collabora on multimedia projects such as PipeWire and GStreamer for 11 years now.
I got started in open source when I was back in high school, around 2003, when I got my hands on a DVD that contained an iso image of Mandrake 7.2. I was very curious to understand what that was, so I followed instructions and installed it without really understanding what I was doing. I rendered my Windows installation unbootable, obviously, so I forced myself to use Mandrake to connect to the internet and find instructions on how to bring Windows back… and I really liked it! Eventually I read more about this unfamiliar environment and the moment I realized that I could modify anything in this system… literally anything…I was thrilled! Unbelievable feeling. I have never looked back ever since….
Christian Schaller: When did you first hear about PipeWire and what is your impression of the project and the community around it so far?
George Kiagiadakis: I don’t fully remember when I first heard about PipeWire, but I remember that it was around summer of 2018 that I started looking into it…. At the time I was working on a project that involved PulseAudio with some cumbersome logic around it and I was not convinced at all that this was the right way to move forward in the future. So, I started looking at alternatives and I saw a lot of potential in PipeWire, which was at its early stages in the audio field back then. The next thing that I did was to book myself to attend the first PipeWire hackfest that we had that fall, where Wim explained to us how it all worked and it made perfect sense.
Regarding the project and its community, the first thing I can say is that I am glad to be part of it! It’s a relatively small community, but very active and passionate. Everyone is polite, patient and willing to help. I am also amazed by how fast things get done, especially when Wim is involved. Before we even finish discussing an issue, he most likely has fixed it….
Christian Schaller: And what was the origin of WirePlumber? What were the initial problems you felt needed to be solved?
George Kiagiadakis: WirePlumber was initially developed for use in the Automotive Grade Linux (AGL) project, where the problem that needed solving was mostly the problem of arbitrating between different audio streams. There is, for example, an application playing some music in your car and at the same time there is a GPS navigation application trying to assist you with directions. When the navigation app needs to speak to you, it needs to be clearly audible, so the music has to go in the background either by lowering its volume or by pausing it momentarily. Or when you receive a phone call, the music has to pause for sure. These are scenarios which are typical in many embedded devices. Our smartphones have similar logic, for instance.
Before PipeWire, solving that problem with PulseAudio was hard. It required developing custom components to define all the rules and logic and circumventing a lot of existing behavior. And it was so bad that people have even tried to work around it and use similar components for the rules, but on ALSA directly, while others have tried to use JACK, which is actually better because it allows an external application – the so-called session manager – to define all these rules without circumventing anything, but there are several limitations. There are actual production systems in automotive and elsewhere that use all these aforementioned solutions, but none is ideal.
With PipeWire, this is so much easier because, just like JACK, all this logic can be defined in this external application, the session manager. But PipeWire also lifts all the limitations that one would have with JACK, like the compatibility with PulseAudio applications, the fixed latency that can be an issue in some cases or JACK’s inability to use different audio formats or passthrough encoded audio to the hardware.
And so, after evaluating all these solutions at the time, it seemed like a great idea to use PipeWire. The only thing that was missing was a session manager that would be capable of implementing all this logic. And this is when the idea for WirePlumber was born.
Christian Schaller: Do you have some good examples of things WirePlumber can do for people on the desktop that were not possible or hard to do before?
George Kiagiadakis: First of all, let me say that for bringing WirePlumber to the desktop we tried to make it behave exactly like pipewire-media-session, which in turn behaves like PulseAudio, so that the transition from one to the other does not change the experience that people are used to on their desktops. So, the very first thing that you will realize after switching to WirePlumber is that… nothing is different. But… behind the scenes, there is a difference.
The most interesting difference is that most of WirePlumber’s management logic is written in scripts, using the Lua language. These scripts can be modified and extended on the spot, much more easily than it would have been to modify the C code of pipewire-media-session. That means that the users now have the power to customize the behaviour of their PipeWire setup to suit better their needs. It is even possible to use the automotive / mobile logic on a desktop, if so desired. That does not mean, though, that modifying these scripts is a piece of cake or that everything works like a charm. There are still rough edges and a lot of things that can be improved to make this a great feature. I hope that with WirePlumber now being part of Fedora 35, we will be able to get more feedback on this feature and evolve it.
It is also worth mentioning that WirePlumber also has the ability to execute Lua scripts independently, outside the context of the session manager, and in addition it comes with a GObject-based library that offers a relatively easy API to control things in PipeWire. That allows power users to more easily script tasks that they often do in PipeWire and application developers to have their applications interact with PipeWire more easily.
Christian Schaller: That sounds really cool, but to be clear are you saying that one can do applications like Ardour or Carla using these Python bindings? Or are you talking about applications that control the session more specifically?
George Kiagiadakis: No, this library is not meant for writing media applications like Ardour or Carla. It only provides functionality to control the session, so it is suitable to write things like a pavucontrol replacement or perhaps a script to automate tasks like switching some card profile, for example, but nothing that involves actual media streaming. We have other APIs to do that.
Christian Schaller: Any major future features planned for WirePlumber or would you say that it is fairly feature complete at this point?
George Kiagiadakis: There are no major things planned in the very near future, but that definitely doesn’t mean that WirePlumber is feature-complete. There are many things that I would like to improve on it and there are also several ideas for new features.
Something that bothers me right now is the configuration system and this is likely the first big thing that will change. Ideally this is something that should be unified with PipeWire, so that the entire stack can be configured similarly and it is also worth exploring potential integration of certain options into the settings dialogs of the various desktop environments.
Another area of interest is to explore bringing more of the policy that is used on embedded systems – the one I mentioned in the example with the car – onto the desktop. PulseAudio was already trying to do something like that, but I think that WirePlumber can achieve more because, with the scripting mechanisms that are provided, it is easier for desktop environments to implement their own customizations and behaviours that are tailored to the UX of the environment.
There are also several ideas for improving the experience of JACK application users when they use PipeWire as their JACK server. The typical case right now is that you need a JACK session manager to be running alongside WirePlumber in order to manage the JACK applications, while WirePlumber only deals with PipeWire and PulseAudio applications. I think we can do better, at least for some use cases.
Finally, I am certain that there will be more interesting ideas and features popping up as PipeWire evolves, especially into the video domain.
Christian Schaller: Any non-WirePlumber features you would love to work on in PipeWire? Like something you personally miss or would love to see improved?
George Kiagiadakis: There isn’t much to miss, to be honest, thanks to everyone’s huge effort to bring PipeWire on par with PulseAudio, feature-wise, especially the early adopters who have provided so much valuable feedback. But still, I do have a few things in mind that I would love to work on.
The first one is the network streaming support. I have used this feature countless times with PulseAudio and there was always some sort of annoyance, especially on wi-fi connections, since the underlying protocol used is not really meant for unreliable connections. PipeWire currently falls into the same mistakes, trying to be compatible, but I think it can do better.
Then there is also a pet feature that I would like to continue working on, which is the support for stream fade-in and fade-out. My colleague Julian and I had worked on this last year and we even had working cross-fade between applications, controlled by WirePlumber, but it was only partially merged and then set aside by other priorities.
Last but not least, I look forward to new video-related features, starting from improved integration with libcamera, to enable modern cameras to be first class citizens on the linux desktop. These are totally uncharted waters that I would love to dip my toes into….
hmm… Among other things, I’m still unable to get Pipewire to automatically switch to my bluetooth earphones when they’re connected. WirePlumber could help with that ?
This should work already, but if it doesn’t for you then perhaps you can try module-switch-on-connect, which is a pipewire-pulse module for compatibility with PulseAudio’s module with the same name.
See also https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/89
First, thanks to all of the developers working on PipeWire and WirePlumber, they are definitely a needed improvement to the Linux audio area, and I look forward to their improvements for video handling too.
It would be great if this article that introduced the addition of WirePlumber to Fedora Linux 35, also had a few how to use it pointers. Like is there a command line option to use it, –help is minimal in use? I use pw-play for instance with a script that I use to play a directory of songs from the command line, I find the audio output is better. Is this affected by wireplumber? I noticed a configuration file option for WirePlumber, how do you set that up, what is it used for?
“Like is there a command line option to use it”
Apparently ‘wpctl’ as in ‘wpctl status’ gives a nice output of status.
I’m still learning it myself but the documentation is here
Default config files copy /usr/share/pipewire/
(system or user settings)
to ~/.config/pipewire/ or /etc/pipewire/
Properties for the DSP configuration.
default.clock.rate = 48000
default.clock.allowed-rates = [ 44100,48000,96000 ]
resample.quality = 15
M 10:05:24.689659 pw.core ../src/pipewire
Good Morning, dear Sir.
Help me the next is the answer a wireplumber that i writed into console
/core.c:190:destroy_proxy: 0x55bc8c6edda0: leaked proxy 0x55bc8c7da5f0 id:34
M 10:05:24.689668 pw.core ../src/pipewire/core.c:190:destroy_proxy: 0x55bc8c6edda0: leaked proxy 0x55bc8c7a4810 id:35
M 10:05:24.689804 wireplumber ../src/main.c:328:on_disconnected: disconnected from pipewire
I’ve been a PipeWire evangelist since I first discovered it 9 months ago. It’s so much better with pro audio (firewire) gear. I can’t wait to give this a try.
I’ve looked over the wireplumber docs and searched for examples with very little success. One of the best being:
I wish that their was some site where users could post their use cases and lua script examples. For example, I have a use case where when I start Reaper I want it to auto-connect its ports to specific audio sources and sinks.. Another would be a desktop “button” whereby I could automate changing my audio routing from my usb audio interface to the computer’s internal audio card.
Keith Smith wrote: “Another would be a desktop “button” whereby I could automate changing my audio routing from my usb audio interface to the computer’s internal audio card.”
like that: https://extensions.gnome.org/extension/858/volume-mixer/ ?
I’m learning a lot, both from the interview and comments. Thanks to all, and please continue!
I didnt knew this was being worked on. Time to find the branch and build from that i guess 😛
Android recently impl this and iOS has been doing this for a while now. Would love to have this on my laptop as well. It doesn’t really add anything feature wise but makes the experience feel more polished for sure.
Had to do this after upgrade to fc35:
$ systemctl –user enable –now wireplumber
Sound works now.
Right now I’m stuck with a 5.1 AV reciever that doesn’t have other way of getting my pc’s sound other than SPDIF/TOSLINK. Because of that I only get stereo instead of 5.1 (even on stuff that is 5.1 like movies or games).
Is it possible to use Pipewire/Wireplumber to at the least get DTS passthrough, and ideally transcode any sound into DTS-compatible stream (with latency compensation) so that anything can be sent as 5.1 instead of stereo PCM?
While I’ve fully into Pipewire, I’ve got a bit of a headscratcher; recently I installed Deepin after noticing it’d switched fully to the KDE rebuild.
But it seems that somewhere, the build/config has gotten in such a way that it literally cannot detect/enable Pipewire.
Given that Pipewire is supposed to be a drop in replacement, therein belies the issue of figuring out where the plumbing is clogged.
I did an upgrade to F35, and it all works fine, except that the Zoom app is not playing any audio. When “wpctl status” run, it seems that contrary to all other applications, Zoom decides to send its output to NVidia sound device, instead of Intel sound card, here is the excerpt from “wpctl status” output:
70. output_FL > HDA Intel PCH:playback_FL
73. output_FR > HDA Intel PCH:playback_FR
60. output_FR > HDA Intel PCH:playback_FR
75. output_FL > HDA Intel PCH:playback_FL
63. output_FL > HDA Intel PCH:playback_FL
65. output_FR > HDA Intel PCH:playback_FR
85. ZOOM VoiceEngine
72. output_FL > HDA NVidia:playback_FL
78. output_FR > HDA NVidia:playback_FR
87. ZOOM VoiceEngine
82. input_FL < HDA Intel PCH:capture_FL
89. input_FR < HDA Intel PCH:capture_FR
So, my question is: how to reconfigure this? Is it necessary to use Lua, or is there some other way? Thanks!
I have a similar problem. When I start Reaper with autoconnect enabled it incorrectly connects to the internal sound card and not my USB audio interface. I can use Carla to re-route everything, but its a pain to have to do this everytime, even after Reaper rendering operations.. It is my understanding that this can be automated via lua scripts, but I’m not finding anything that’s 101 cookbook level on how to properly configure wireplumber to do this on Fedora 35.. Do I copy everything from /use/share/wireplumber to /etc/wireplumber and make modifications there? How. Does one do this?
How does pipewire and wireplumber change things from an application development standpoint? It’s great to have a way to wrangle all these legacy audio streams, but if someone is starting “from scratch” on new code that needs to create sound, what’s the current best practice? Web searches for “Linux audio API how-to” turns up a lot of results from between 2002 and 2012; more recent results seem to center more on which already written applications to choose. Given the current state of the art, how should new code produce sound on Linux?