Tech Over Tea - Creator Of Pipewire's Wireplumber | George Kiagiadakis

Episode Date: December 19, 2025

Today we have the developer of Wireplumber on the show to talk about what it does, why it exists and how the project came about==========Support The Channel==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson==========Guest Links==========Pipewire Website: https://pipewire.org/Wireplumber Docs: https://pipewire.pages.freedesktop.org/wireplumber/Blog: https://gkiagia.gr/==========Support The Show==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson=========Video Platforms==========🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg=========Audio Release=========🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw==🎵 Anchor: https://anchor.fm/tech-over-tea==========Social Media==========🎤 Discord:https://discord.gg/PkMRVn9🐦 Twitter: https://twitter.com/TechOverTeaShow📷 Instagram: https://www.instagram.com/techovertea/🌐 Mastodon:https://mastodon.social/web/accounts/1093345==========Credits==========🎨 Channel Art:All my art has was created by Supercozmanhttps://twitter.com/Supercozmanhttps://www.instagram.com/supercozman_draws/DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I'm as well as you're host, Brodie Robertson. And the way we do Linux audio has changed quite a bit over the years. Nowadays, we're doing a lot of things with pipewire. And a core part of pipewire is the session manager. And today, we have a person here who is very involved in that, who without this person here, we probably wouldn't have the one that we mainly use nowadays.

So how about you introduce yourself and we'll just go from there? All right. Hello. I'm George and I'm a software engineer working on pipe wire and wire plumber. I'm mainly known for wire plumber. I wrote wire plumber basically from that whole stack. by wire was written by WIM and yeah that's that's an amazing intro about me I guess

short and simple intro I like it sometimes people go for like five minutes I don't know when they're going to stop I can't ask a question but you know that works as well I think we should probably start from there's a few ways we can approach this

I think the best way to start is sort of explaining how Linux audio works, how pipewire fits into the stack, and then we can move into the whole session manager stuff. So, yeah, I guess this could be an entire conversation just by itself, but how does audio work on Linux? Like, what is actually happening here? Right. So at the lower level, you have ALSA, which is...

component of the kernel and this is the component that interacts with the sound hardware the audio devices and it exposes them to the user space to the applications that are running on our session nowadays with pipe wire how this works is that pipe wire runs on top of that so it's exactly the layer above alpha it grabs your also devices it opens them uh configures them the correct parameters and then creates the appropriate objects that allow applications to basically connect to pipe wire and link to that sound card and get access to the sound card and either play audio or record audio from there um so Yeah, I don't know how much in detail we want to get.

You can go into as much detail as you want to. As a starting point, right? I understand that this topic is such a broad question that you could just spend the entire conversation just talking about this specific question. Yeah, right, right. So pipewire is basically something that sits between your applications and the sound. card and it's it started from something else actually it started from being a video device broker let's say it's something that was supposed to connect your cameras and give access to applications to those cameras right yeah something may know that originally there was the discussion

of pulse video exactly yeah it started from pulse video it was actually being called past video initially, yeah, and then it got renamed twice until we reached pipe wire. So that was the original idea, but it seemed like something more generic could be done out of it. And so Wynne built the support for audio devices as well and also other things. And I think it was modeled as a generic multimedia bus that if you, if you, if you what's my talks, I often refer to it as a multimedia bus. It's not really an audio server. It's something that allows to transport media from one place to the other. And these two places can also be two applications. So you can have application A, application B, and then

these two link with each other and they transport media, either audio or video from one point to the other. Or MIDI, right? It supports MIDI as well. An example of this being what we're doing right now. I'm taking the audio from Discord, I'm sending it into OBS. Exactly. Yeah, OBS is a great example of that. And you can take audio from Discord, send it to OBS.

Also, OBS will be capturing from capturing the video from your Wayland Compositor. And then, so the Wayland Compositor connects the pipe wire. It sends the video there, and then

other applications can grab it. So this is the generic mechanism. And then one of the, let's say, plugins there is the ALSA plugin, right? The support for accessing audio devices. And yeah, how this works is that it has a system there which detects your audio devices and tries to make out the best representation. of what's out there because on the ALSA level it's just a device handle which you can open with different parameters it could be you could set different rates different channels um you can do crazy things but it's not really something that's user friendly right so pipe wire sits in the

middle and it tries to detect what's on your sound card using some configuration as well there and Yeah, then it basically creates those more user-friendly device objects that we see on the, on, let's say, pavu control. When you want to change your profiles and change your outputs, you normally use pavu control or Gnome settings or KD audio settings or something like that. This is where you see the devices that PipeWire has detected and you can change there. And that creates nodes, then the nodes can be linked to applications. And that's pretty much how it works. Now, if you go on the internet and look how audio on Linux works, you might get confused because people will say, oh, we have all of these frameworks, right?

We have ALSA, we have Pulse Audio, we have Jack, we have pipewire, we have GStreamer, we have VLC, we have, I don't know, a bunch of things. If you're really old, you might know open sound system. Open sound system, yes, of course. It's not really relevant today, but still part of that older competition. Yeah, it's not really relevant today, exactly. And all of these are basically different components that sit at different levels. But if we're looking at the modern stuff, what we use today, it's basically that.

It's also on the kernel level, then pipe wires sits on top, then applications which might be using GStreamer, might be using VLC, might be using some other library, like FFMPEG or whatever, and they talk to PipeWire through that, and PipeWire talks to also. That's the whole stack nowadays. So we also have the, you were saying about these plugins. So we have like the Pulse Audio plugin, the Jack plugin, the Gstream plugin. So applications are expecting a certain API, and that's sort of why those plugins exist.

It provides a way for those applications to interact with PipeWire through the language they already know? Yeah. So for compatibility reasons, we have, we support different APIs on Pipewire. Of course, PipeWire has its native API, but then we have also the Palsodio API and the JAQ API. So all the applications that were previously talking to Palsodio

through the Palsodio API can still work, and function as they were before by just talking to the pipewire server through the Palsodio API. And that Palsodio API is basically using a socket, a Unix domain socket, where all the, the original Palsodio library writes commands into that socket, and basically pipe wire sits on the other side and it listens to that, to these commands, and it responds in the same way that Pulse Audio was previously responding. Same for Jack. No, Jack is a little bit different in how we have done the API emulation.

We basically don't use the original Jack library, but we provide another library, which is the replacement pipeware jack API library. And applications, instead of calling the original functions from the Jack library, they just link to a new library, which provides the same functions. And they call those, and then this library translates the commands directly into pipewire native API calls. So what happens there is we, the JAQ applications actually use the native pipewire socket to talk to pipewire, just using the JAG API on their end to talk to the library. I did not know that. Okay.

We already learned something today. Yeah. Yeah. And finally, we have also the ALSA compatibility. So some older applications want to talk to ALSA directly. So they just go to ALSA and they try to open a device and, you know, send audio there. And what we can do with the ALSA user space library, ALSA LIB, it supports loading plugins. So basically the application that talks to ALSA, it doesn't actually try to open the Rural kernel device directly, but what it does, it asks the ALSA library to open the device. So the ALSA library then can load a plugin, and that plugin knows that pipe wire is running. So it uses again the native pipe wire API to talk to pipe wire. So it talks

through the socket to pipe wire directly and you get the audio like that way. Right. So again, it's going directly to pipewire through the native pipewire socket. Okay. So these are the three APIs we have. Yeah. Go ahead. Okay.

So I guess there's probably a lot of ways to answer this, but why have we done this move from Pulse Audio as the main thing that applications interact with to this migration into pipewire? now that, you know, it has this, I assume part of it is the fact that it has these plug-ins to interact with all these different APIs, but is it more to it than just that? Is it the fact that it also has this video capability, which is obviously relevant on the Wayland side? Do you have maybe some insight into why this shift has been happening, basically across every district? I think most have pretty much adopted it just by default now. Yeah, well, the adoption is driven by where the community wants to go and since Palsodio is being phased out even by its maintainers, the maintainers are saying publicly that they support pipe wire now. So that means that Pulse Audio is going to be unmentained in a couple of years and obviously we need to switch. So that's why people have been switching.

But besides that, pipe wire is just a better implementation of the whole thing. And when I say better, I mean there's a couple of reasons, right? One reason is the latency. So with pipe wire, because it targets also the pro audio use cases and it targets also emulating the Jack API, it has been built with a very different architecture internally, which allows it to deliver audio with very, very low latency. Even beating Jack in some cases, right, at some benchmarks. And that is something that Pulse Audio was never able to do. It will never be able to do. It has to do with internal architecture, how things are handled internally. If we wanted to

make it transport audio with low latency we would have to rewrite it but you know we have pipe wire now so it doesn't make sense um then i guess the other thing is that by having all those use cases built into pipe wire by having pulse audio and jack use cases built in now we don't have to fiddle with the actual JAG audio server. So on default setups, desktop setups, you can run any application, even if it's a Palsodio application or a Jack application, and it will work. That's something that was really painful for users to set up in the past, where you would have to either remove Palsodio, move it on the side and let Jack take over, and then if you wanted your browser to work, then you had to change your browser settings as

well to talk to Jack. If you wanted other apps to work, it was a frustrating thing to make it work. And we had setups where Pulse Audio would run as a client to Jack. So applications would talk to Palsodio and then Palsodio instead of talking to ALSA, it would talk to Jack and then Jack would talk to ALSA. So we were stacking things up. And this is a setup that, you know, it works, but it's not trivial to set up. People didn't have have a great time like doing that and it felt difficult. So one of the reasons is, yeah, being user-friendly as well. So I guess this takes us into the discussion of wire plumber then.

I'm sure we can keep talking about that side for quite a while. But my understanding is pipe wire doesn't by itself do any sort of internal routing. And that's sort of what the point of the session management or at least one of the points of it. Yeah, so pipe wire supports creating links between nodes, right? This is what the functionality of pipe wire is. I create nodes, which are the basic units of audio processing or video processing or whatever it is, and then create links between them which allow the media to move from one side to the other.

But PipeWire will not create those links automatically for anybody, right? So when an application connects, it just sits there. There is nothing linking it to your device or your other application, whatever it is you want to do. Now, if we look back, Palsodio, it had built-in rules to do that. when you were connecting to Pulse Audio and you were asking to play audio to the default output, Pulse Audio would automatically link that application to the default output internally. And so you had this experience where the application connects and it suddenly is able to play. With PipeWire, that's not true. So if you're not running a Session Manager, connect to PipeWire,

nothing happens. So there is a need to have something there that implements this logic of, okay, I have this new node here, what do I do with it? And that's why Where Plumber was created. And where Plumber has, by default, it has the same logic as Palsodio. So that's how we started implementing things. We thought, okay, we want compatibility. So we have to basically bring the same user experience from Palsodio into pipewire. So yeah, it does similar things. Like if a new application connects and it wants to play to the default output, then wire plumber gets notified. It looks at that application node.

It sends a command to configure it to the appropriate channel setup and sample rate set up and all of that. It has to be configured initially, and then it creates links to the device that it needs to go. That's the main thing that wire plumber does. It's not the only thing, though. So wire plumber will also, first of all, manage the devices. So when pipeware starts, again, it doesn't do anything. If you start pipe wire by itself, it's an empty graph. There's nothing. Somebody has to create the nodes for the devices. And that's where Plumber comes in again. So it will load the plugins that talk to devices, like also devices, if you do for Linux

devices, for your camera, bluesy for Bluetooth devices, all of these things. Are you still there? Yes. Can you not see me? I think it's frozen. Hello? Hello? Are you should I'm the one with problems? Uh...

Hello? Hello? Yeah. Are you still there? Okay, you're... Yes, it was frozen for a minute. I don't know where you cut off. I'm usually the one with tech problems.

This is new to me. I don't know. Is it my connection? it my connection? Maybe. I don't know what happened. That's fine. So you're talking about how wire plumber manages your devices. Yeah. So I said about how wire plumber basically is the one that links your applications to devices. But then where plumber also does more things. So one of the things it does is it manages your devices. When pipeware starts, it doesn't do anything by default, it's an empty graph. And then if you need to, obviously you need to see that your

device is there. So wire plumber is the one that creates the instances of the plugins that will talk to the devices. Your ALSA device, your video for Linux device for your camera, your bluesy device for connecting to Bluetooth headsets, all of that is managed by wire plumber. And then as soon as it gets notified about, you know, actual devices being there, it will create the appropriate nodes. It will select the appropriate profiles as well. Taking care of remembering your preferences. So when you change your profile for a card, that's something that wire plumber handles. And it also, wire plumber saves the state and restores it afterwards. So restoring things like the volume level? Is that? Volume level, yeah. Volume level.

both for the device and the applications. This is something that wire plumber manages. Restoring profiles, restoring channel setups as well, and things like that. Another thing that it will also do is manage which one is the default device when you select it on your preferences. That's something that wire plumber will also remember. And it will also select one appropriate choice when you first start up, when you don't have any other default saved on your state files. So you will select one default and it will manage. It will always keep one default device so that the policy always works.

When you start an application, it will link to the default device. And something else that it's supposed to do is manage application permissions. So that's something new as well, coming from Palsodio. In Palsodio, we didn't have access controls at all for applications. So basically, every application that would connect to Palsodio was able to change anything on any device, on any other application. It was able to do anything. And if it had a malicious intent, well, tough luck. Right, so any application could just listen in on the audio and it just nothing could stop it.

Yeah. Yeah, it could listen. It could listen. It could also change volumes. It could do crazy things like... I see. Yeah. Yeah. So like you could just suddenly throw it to 200% volume and that's not pleasant. Yeah, and then blast your speakers or something. Yeah. So in Pipwire, we have access control. built in by default and that means that every client that connects, every application that connects, has its own set of permissions for each object that lives in the graph. So every other node, every device, every link, every port, all of them have permissions, read, write and execute methods. So when a new client connects, wire plumber has,

Wire Plumber has the ability to basically say, okay, what is this client? Is it allowed to access this and this and that and apply the permissions? Now, at the time of speaking, this is not fully deployed yet, right? So we still don't really apply permissions. We let applications do whatever they want. We apply full permissions. But this is something in the works. we are working on it. We want to have a framework where the support layer is there. What we're

missing is the wear plumber policy, basically, to manage those permissions. And we want to have a system where we can say that, you know, this application is, let's say it's a music player, it's a playback application, so it should have access to the audio output by default, but probably not access your cameras or not access your microphones or things like that so that it cannot really do something I intentionally and change your setup there. Or if it's an application that you've installed from an untrusted source and you probably are using flat pack or something similar to restrict it, then we apply even further restrictions unless the user choose.

user chooses to lift them, right? So that's the idea. That's where we want to go with that. I can see how early ideas might miss some weird use cases. Like, an example that I have is something I actually do. I route the audio from my capture card to my speakers. And that's a relatively normal thing to do. but I do know there's some people

that have some weird audio setups that because there's no permission controls on anything technically work so I do expect that once that is like properly rolled out there's going to be some there's going to be some regressions that appear

that aren't intentional but our use cases that weren't entirely clear because you know people do weird things when they're allowed to do weird things Yeah, I understand what you're saying. It's true that people have weird setups and they do crazy things with their setups.

And we constantly get reports about things that people want to do that are not... Good ideas? No, they're good ideas, but they kind of clash with policies that... we have set up and you know sometimes we roll out a new policy and people are just confused they're like oh this is a bug this doesn't behave as it should um recent example we had um somebody contributed a module that when you when you're playing music to your headphones and then you unplug your headphones, either physical or Bluetooth, and then I think the main idea was for Bluetooth,

so let's say you have your Bluetooth headphones, you're playing music, and you take them off, you unplug them, you turn them off. And that module basically goes by default and poses your player so that it doesn't blast out of the speakers. Yeah, this is a pretty normal thing that phones do. That's a pretty normal thing phones do, yeah. I know also other operating systems do it like I use macOS as well I know macOS does it that way and it makes sense for a lot of users but yeah when we rolled it out there are some people that were

saying oh what's going on when I unplug my speakers it poses my player this is a bag and they started reporting bags to to the player initially like it was the player's fault initially but no this is a normal thing this is a it's a policy that we rolled out Same thing happens with people that use, you know, speakers on their monitors. So they have an HTML connection, they have speakers on the monitor, they want the audio to go there by default. And there are other people who have an HTML monitor that has speakers, but they don't want, they absolutely don't want audio to go there.

So there's different... I use wire plumber to literally disable that node. I do not want to see it. Yeah. So you are on that group. And there's the other group that they want that route to be always used. So they expect when you plug a monitor, they want the audio to go there. And there is no good solution. We offer options, basically, but there's no good default that we can say it satisfies everybody.

So yeah, that's my point there being that, unfortunately, where Plumber is, well, it's a policy tool, right? So we have to make up good defaults for a lot of people, but it won't be good defaults for everyone. And the only thing we can do is provide options, and we try to provide options where it makes sense so that people have a way to easily switch or change. Yeah. So I hope that this won't disrupt your setup, but I'm pretty sure we can find a way to add options to make sure that doesn't break completely what you're doing. Well, mine's pretty normal. It's not that crazy.

It's just taking audio from a device and then sending it to a speaker. So that should, you know, that seems pretty normal to me. Yeah, I think it should do. It should work. And, you know, I don't think we are going to get very invasive with permissions initially. permissions are generally more useful for untrusted setups. So I think we would be more enforcing more restrictions on flatpack apps, which are by default not trusted.

But then for native apps, we would probably give more permissions, something like that. I think that would be a good default. But yeah, then we would have options also for. for devices that we work with. So that's one of the main things that I do at Collaborate is we help customers build devices using that software. And of course, there we have other levels of restrictions that we want to apply. We have other kinds of policies that we want to apply. And all of that has been built with that in mind as well.

So it wasn't built exclusively for desktop users. It wasn't built with that in mind. It was built with how do we take that and make sure that the device works correctly. And on that context, yeah, we will want to apply more restrictions and also do more crazy things. Let's say that desktop people will not see By default.

Yeah, I'm kind of interested about that because I know that in the past you have talked about pipewire and automotive grade Linux. So, what sort of requirements exist that don't exist in the desktop space? Right. Yeah, so in automotive, if you, yeah, if you, if you, how do I start from that? Basically, as like a start, just explain what automotive grade Linux is and then we can sort of go from there. All right, yeah, that's easier. So automotive grade Linux is a project that aims to bring automotive companies together to collaborate on common software that they use.

It's clear that automotive is going to the so-called software-defined vehicles where basically the hardware, the engine is pretty standard. is nowadays it's just the motor and a battery like there is nothing there is nothing there all of the complex engineering that was being done for internal combustion combustion engines is gone so what's left and what is the value that that they bring to people and it's mostly the software right and we have from basic infotainment software which has been there for a long time actually things that like playing music or playing video on your car to very complex use cases like autopilot like taking control of your car and doing all sorts of crazy things there and all of the things in the middle like this there is a lot of lots of crazy use cases there

when it comes to software so automotive comments are moving to software and in order to do that they need to have they need to start from somewhere they obviously use a lot of Linux on it or they want to use Linux there is also other operating systems they use that are targeted to automotive specifically but yeah Linux makes a lot of sense so they try to make a platform based on Linux and automotive grade Linux was an is an effort still to bring all of those manufacturers together so that they can collaborate and they don't have to reinvent the wheel every time they want to build a platform. So they maintain a base distribution, a Linux distribution based on Yocto. For those of you that don't know, Yocto is an embedded Linux distribution.

It's a distribution that it's basically something like Gen 2 Linux. It has a set of recipes that built the software it's not pre-made packages and it's targeting embedded devices so automotive great Linux is a distribution that builds on top of that and it provides basic software and configurations that make sense in a vehicle and yeah there are some some companies that build their platforms based on that they take that as a base and they built on top Now, if you go to a trade show or a conference and you see automotive-grade Linux demos, you will see that there is a user interface as well, where you can play with things and play music and see your engine revs moving and things like that.

This is a UI that is supposed to be a demo. It's not something that you can actually install in your car. supposed to be the thing that people will see and test with when they build an automotive grade Linux, but then as the actual companies who are building the car take the software, they remove that and they bring in their own UI and user experience. So where we were going with this was we're talking about like pipe wire in this space. So what requirements differ when we're talking about this space? Like, what are people looking for that may be different from the desktop?

Right. So a typical desktop has two speakers and a microphone, right? That's the main setup. Now, in a car, you can have a lot of speakers, crazy setups. And a lot of microphones as well, crazy numbers of microphones in all places. And there can be very, very simple use cases, like you play a music file or a stream or radio, and it plays all over your car to all the speakers. So that's nothing. That's very easy. That's basically a desktop use case. But there could be cases where you separate the car in zones,

So you have something playing over here, something playing over there. You take input from the microphones and you do crazy amounts of noise cancellation and a voice isolation. So you can speak. You're on the driver's seat. You speak. You're talking on the phone and it's only you that can hear what's going on and speak to the phone. There are these kind of setups in very high-end luxury cars where. I think... I think I lost it again. Hello?

Hello, I can hear you. Ah, Discord, Discord. What a great platform this is. Okay, Discord, problems, we're on Jitzi now. So, yeah, let's just keep going. Great. So I was saying about, you know, that the car has... you know that the car has a lot of speakers and a lot of microphones and there are use cases,

for example, where you isolate one person and you direct the audio towards one person and you grab the voice from that one person and you do crazy amounts of noise cancellation to make sure that nobody else can hear what you're saying on your call and things like that. Now, of course, we don't do all of that in software in automotive grid Linux. What we do is, this is a crazy use case that very few manufacturers do and they do a lot of hardware there as well still today, with their intention being to move the software down the road. But what we do is we basically have policies to differentiate between streams based on the use case of the stream. So there are streams, audio streams that are basically music or media that you're playing.

And then there is another audio stream that can be your voice assistant, navigation assistant. And then maybe there's another stream where you're in a call and you receive audio from that call and you're speaking on the phone. So these kind of streams need to be handled differently. If we were applying the default desktop policy, we would basically be routing all of them the same way just as we do on desktop. So if you start a call on your desktop with GTC, Discord, whatever it is, that doesn't stop your music.

That doesn't change anything on your volume levels. It doesn't do anything in particular that recognizes the fact that you're in a call now. In a car, there is a different policy being applied. So if you are in a call, then audio music will stop and we will make sure that even if the application misbehaves, it won't be audible, it will be just isolated and won't go to the device. Same way for navigation assistance or voice assistants. There is another policy there that will say, okay, when the voice assistant is speaking,

if there is a music at the same time audible we lower the volume of the music so that we can hear what the assistant is saying these are also common things that happen on mobile phones so the policy is not very different from from what you have on your Android or iOS device it's basically similar stuff and and there is also there are also volume controls for each use case so there is a volume control for multimedia volume control for voice volume control for calls, which is, again, same thing as it happens on mobile phones. So that's the main thing that is different today in automotive grade Linux versus the desktop. So in some ways, you're less concerned about the individual audio devices,

and you're more concerned about the audio contexts. Exactly, yeah. Yeah. This is something that could also make sense on the desktop. and actually on our last update on this functionality we added support for being able to run this kind of policy in parallel with everything else on your desktop so if you want to try it on your desktop it's there you can enable it and you can configure your streams to have a context and then this policy will be applied right and some some people use it some people want to have

a voice assistant for example and they want to prioritize it and duck the music that's a common case that people ask for and it works also on the desktop the problem with the desktop though is that not all the applications will provide context of what they are what they do especially web browsers are very tricky to get like to get the context because a web browser can be playing music, it can be playing advertisements, it can be playing a video, it can be playing a call like we are doing now on Zizi. So you don't have that context and there is no browser API to let the website give us that kind of context. So yeah, there is no way to know. And basically that's why that can't really be the default on the desktop.

we don't have enough context. Right. Okay, that makes sense. And especially as, you know, a lot of applications move into the browser and you realistically could do a lot of your computing just in a browser, without some sort of extension to web APIs, which could possibly have some value, you can't really do much with that. Yeah, currently we don't have the APIs, right? So there is no way we can do something.

And there are websites also that might have different streams from different use cases that go out as one stream on pipeline. Right, like an ad playing and then the actual content on the page that you want to see. Exactly, yeah. They can be the same stream as far as pipewire is concerned. The browser can do mixing and it can do things. It depends on the browser, of course, and it depends on how the web API is being used. But yeah, there are this kind of use cases and there is no way you can tell what it is and isolate different streams and does anything meaningful with that. So one thing, we're kind of jumping back a little bit. One thing we didn't really talk about, so we talked about how wire plumber does this linking, but what didn't come up is that even though it is doing that linking, it doesn't prevent the user.

from doing additional manual linking themselves. Like, as I was saying before, with the taking the capture card audio and then sending to my speakers. And you can do this. This is like a CLI tool to do this, but a much better way to visualize this is through a tool like QPW graph. And I think even if you don't mess around with it, I think it's worth opening it just to see what is actually happening in the background and how things are actually being linked together.

I think there's some value in sort of understanding what PipeWire is doing and as you like open new audio sources and just see how much complexity there is that you don't generally have to think about. Yeah, indeed. And that's one of the great things of PipeWire is that you can visualize all that information in a graph tool and change things, make your own links. It's really powerful. You can do crazy things, crazy setups, especially as you bring on Jack applications, which expect this to be there, right? So Jack traditionally had those tools for decades before it became a thing on PipeWire. And that's where the inspiration is coming from, right?

And of course, yeah, PipeWire gives you the first. freedom to do anything you want. And wire plumber won't stop you from doing that. But at the same time, there can be cases where if you don't understand what you're doing, you might be breaking things that where Plumber is trying to do one thing and then you are trying to do something else with your links and that might conflict and you might see weird things going on. But I think those are more rare cases as generally people, understand what they're doing when they open these tools and they don't mess it too much. I hope.

No, I've definitely put myself in a situation where I didn't exactly have a good way to recover from it. But at the end of the day, if something does go really badly, just, you know, kill off pipe wire, restart it, it'll fix everything, probably. Something that wire plumber doesn't do today, and it's on my... my, it's on the back of my head on my to do list, is to track what you're doing on the graph tool, right? So if you're, let's say, if Werplumber creates a link and then you go and destroy it in the Graph tool, Werplumber doesn't know that you've done that. It doesn't track that you've destroyed a link.

So it still thinks that the application is linked and then if you're expecting it to do something, If you completely unlink it and then you expect Wireplumber to recreate the links, for example, it won't do it because it thinks the application is still linked. Similarly, if you go and create different links of that application to somewhere else, again, it doesn't know that you've done that. Right. So this can be the cause of trouble if you like this is why you can end up in a setup that doesn't work. And yeah, it's something that would be nice to have at some point to be able to track those links and have an understanding of what they usually is doing so that when things start to break, you can take actions on Werplumber site.

That actually makes a lot of sense. I didn't know that, but that explains exactly why I have to open up QPW graph every time that I want to get the audio from my capture card to myself. speakers. It, I guess it's, QPW Graph is just loading the profile that it itself has saved so that it can return me to the state that I wanted things to be in. Yeah, QPW Graph also has the functionality of saving the links and restoring the links. And in essence, it's, it's another session manager that works alongside Warplumber in this case and creates its own links. Speaking of, it's generally possible to have multiple session managers running at the same time. That's not something that pipe wire will prevent you from doing. So you could have even

jack session managers, traditional jack session managers that save and restore states to be running alongside where plumber, as long as you are careful enough not to have them interfere with each other so if you as i as i'm saying wire plumber doesn't track what you're changing on the other side so if you if you're if your jack session manager or kbw graph or whatever it is is changing the links that create were created by wire plumber then wire plumber doesn't know and it can be it can get in a state where it doesn't work as expected but if you are isolating those in your mind at least so you're you're creating the jack links with the jack tool and let wire plumber do whatever else is there it's doable it's possible it works and it's also the recommended way

it's the way that we recommend people to work with jack applications because jack applications are not being handled by wire plumber because there is no single policy that can apply to them, right? There are nodes with wide number of ports that do all sorts of crazy things, and there is no way that we can understand how these are supposed to be linked. It depends on the application. It depends on what you want to do. So the recommended way is there to use a JAX session manager or QPW graph or a tool like that, and create the links that you want, save the state, and then have the tool restore it. now I understand why you said the QPW Graph is kind of like a session manager if you are using it

because I guess that that is kind of how I've used it in many contexts where I will open up a jack client from the OBS side and then connect all the audio like that I don't I know the jack tools exist but I'm using QPW Graph for other stuff anyway so for me it just makes sense to do all of it with this one tool Yeah, that makes sense Especially with Usually when you're dealing with Jack applications You're dealing with professional audio So there's usually going to be a very specific setup

That users want from that And trying to assume what that's going to be You're just not really going to ever be To get yourself To work out what every random professional audio set-ups Just It's a waste of time trying to work that out, right? I think is pretty much the point you're trying to get

there. Yeah, yeah. I mean, you can do all sorts of crazy things, right? And it makes sense to, yeah, I think people are sensible in how they use these tools. If you're using Jack, I think you know why you're using Jack. Exactly, yeah, yeah, yeah. You're using Jack probably because, you know, you have a reason you have a specific use case that cannot be done in any other way. So that's what Jack brings to you to the setup. And yeah, of course, we're saying Jack, but we don't mean actually running the Jack server. You can do all of that on Pipwire. But we mean Jack applications and Jack APIs and basically treating pipewire as if it is a Jack server.

So Wire Plummer is what everyone has basically adopted now but there was another main session manager everyone was using previously that has now been deprecated that being a pipewire media session so

what was different about that and why does wire plumber exist I guess is the simplest way to put it that's a great question Yeah. So wire plumber started back in 2018, I think it was, where we were focusing on automotive with use cases. We started as a session manager for automotive grade Linux initially because at the time, automotive grade Linux was using. was using ALSA, basically, it wasn't using Palsodio even.

It was a custom setup on top of ALSA. I was doing crazy things that didn't fully work. And I brought in pipe wire and I said, okay, this is the audio server that we're going to be using in the future. Everybody is going to adopt that. This is the new thing. And we decided to adopt pipe wire in AGL, but the problem was that there was no

Session Manager. It wasn't creating links. And we needed some tool for that. So work number was born out of that use case. And at the time, PipeWire was still in the 0.2 version. It was like before it was popular. And there were a couple of things being done differently there. And we had to come up with structures.

to make all of that work and we spent a lot of time on that and we spent time also creating the tooling for AGL make sure we have everything now as we focused on the AGL because we had quite hard deadlines as well we had only a few months to come up with something we didn't pay attention to the desktop so we didn't create desktop policies we didn't touch any of the Pulse Audio-like functionality and we didn't even think about it. So the initial version was not designed to be able to be expanded to Pulse Audio-like functionality, right? It was very difficult to do that. And so, I guess it was one year later or so, we started looking into that and we had to rewrite a lot of things. And I was taking a long time and

the Fedora people were eager to get pipe wire out the door on Fedora. And they were kind of pushing WIM, I guess, to come up with a solution to have something because wire plumber wasn't ready, even though it was seemingly the best approach for the future. Because we were building wire plumber in a way that's modular. And also we wanted to integrate scripting. We wanted to integrate all of these features that would make it a good end user tool. But we didn't have any of that. So WIM started writing the pipe bar media session, which was a very simple version of all

of that, all written in C with hard-coded policies, with no settings. It was basically trying to do whatever Palsodio was doing, hard-coded, no possibility of changing anything, just make sure that the basics work. No customization whatsoever. And it was clear from the beginning, right? This tool was created just to be able to support the transition from Palsodio to pipe wire. It was to get something there so it could be done. Yeah, exactly. Just to be able to support that and work for the initial transition so that people could also test it because Pipwire was not something that people could use because they had to understand how to create links themselves.

So it wasn't the tool that was actually usable even among developers. Developers wouldn't know how to do that. So you had to teach them. And we didn't have the graph tools as well, that the UI tools we have today so you had to do it on the command line and the common lines is um it's tricky right um yeah yeah basically it was a tool to get things done but we knew from the beginning that this was not going to continue for a long time and we started porting wire plumber to uh to a new architecture at some point that was able to accommodate all of this desktop policy and at some point when we had something ready we started showing to people how they can transition from pipe wire media session to wire plumber and how to run that and our initial goal was to be on par when it comes to functionality have exactly the same

functionality but then we we surpassed that we have more functionality today and And, yeah, as it became stable and usable and had more functionality, we decided to duplicate by quorum in the session. It's as simple as that. Okay. So, yeah, it was basically just, it basically just needed to be there so that the transition could be done, that people could test it. And I guess with Fedora kind of pushing for it, if I remember, if I remember my history correctly,

that probably would have been not long before there was like a lot of work done to get video capture done on Wayland and there wasn't really a generic way to do that before so I guess that probably aligns with that they saw pipewire was going to be a thing that could do this because before Gagnone was doing their own thing

and W.R. Roots had their own thing and Katie had their own thing and that just that was never going to be viable for an application like OBS you could never really build a generic screen capture tool like that because everyone would just have their own different thing. I think, I want to say 2020 is when OBS got screen capture support on Whalen, something like that. I don't, maybe 2021.

I know it was around that era, though. Yeah, I don't remember myself when exactly it was that. But yeah, it was all driven by the Fedora developers and they wanted a solution to allow So basically, yeah, screen capturing, but also passing through that video to flat pack applications. And there was a lot of development around that. And basically, as I said earlier, much earlier, pipe wire was initially created for that. It was created for passing video around from cameras to applications, but then it was clear that this could also do screencasting. So all of that was developed.

And PipeWare Media Session was also a way to get that actually working, to have something create the links for you so that it works. And yeah, it's been supported like that since then, even in Wire Plumber. So I guess we haven't really talked much about, configuration you can do to wire plumber. Now, I did make a video

and I probably should change the title now because I made a video on this prior to the format change. So that video is entirely outdated now and everything in it is wrong. So originally

the format was a Lua configuration file. Was that correct? Correct, yeah. so why did it change right so i guess i need to take this from from the top and start with why lua in the first place how how did we end up with lua in the initial stages of wire plumber we were writing all things in c just like pipe wire media session and we didn't have a lot of configuration and at some point we understood we needed you know some level of

configuration people to be able to change things the thing is well around the time we had a hack fest I remember we had a hack fest I don't exactly remember where it was but I remember like it was we were sitting down at the table with weem and others and one of the guys there boston he had come up with this idea to use lua for configuration at the time i didn't know lua i didn't understand it as much like I knew it as a, I knew it existed that that was all I knew basically and that it was used in some old games as a scripting language. Right.

That's pretty much my knowledge about Lua, that was my knowledge about you at the time. So this guy brought the idea in and he said, he tried to convince us that, you know, this is something that is easily embeddable in a software that can also go into a device but also it is very easy to write it has all those very simple data structures that you can write scripts with and it can basically support the configuration system with a scripting language which would allow for more flexibility in the future at the time I didn't know Lua as I said so I didn't go for it immediately I

we were in a rush to get things done for AGL. And so we invented a T-O-ML-based configuration file, a T-O-L file. We brought in a Lib-TOML something. It was a library, C++ library that we were using to parse that and write that. And we implemented that, but of course it was very, very limited. We have only a few options and it was pretty much constrained to the default. old policy. And after we had fixed that for H.L and the deadline was out of the way and

we had everything working there, we started looking into Lua. And there were two things in Lua. It was initially suggested as a configuration format so that you can create a script that basically configures how you want things to be done in your graph and toggle some options and things like that. But it was evident that it was also a scripting format where we could write logic, real logic, actually policy logic there. Without thinking too much about it, we adopted it for both.

We wrote a scripting engine. And then, well, I said, OK, let's use that also for the configuration. So we had one engine basically that was supporting everything. And note that at the time, pipe wire didn't have a configuration file. So pipe wire was not configurable. We didn't have anything. No, actually it had a configuration file, but it was a very, very minimal configuration file with a custom parser that was each line was parsed separately.

It was like an in-e-format configuration file. Something like that. It was a very simple thing just to configure which models you want to load. things like that. That was not something we could take on in Werplumber. It wasn't giving us enough options. So we thought, okay, what else do we have? We can continue using Toml or we can go into Lua which gives us more flexibility or we can pull in another library that does something else like Jason for example or something else. But I didn't like the idea of bringing in more dependencies. I had LUA there, so we used that. And so it was built like

that and we had the scripting engine which allows you to build the scripts that have the luxury linking logic and we had the configuration files that were toggling options, basically toggling settings and deciding which modules load and things like that, also in LUA. Now that didn't work very well because people didn't fully understand how to use that as a configuration file and they were also very very confused about yeah very confused because you know there was the scripting in lua there was the configuration in lua they couldn't understand what's the difference between those two and where does the lua file go because if you put it there it's a script if you put it there it's a config file and they didn't understand also how to

override things because you had to think as a programmer, you had to think as if all the Lua files are being concatenated together and then there is a parcel that goes through every line and runs the program. That's how it was working. People didn't grasp that so they were basically copying the Lua files from one place to the other. We were shipping them in USR share as data files and they were copying that in their home directory and they were changing things there without overriding and overrating was hard. And that led to a lot of problems because as we were changing the default configuration, for example, to load new modules that we implemented, people who

had copied their files didn't get the new modules. And then there were Plumber was crashing because it was expecting things to be there and it wasn't there. It was a mess. Yep. It was a mess. I was right there with it crashing. there was an update that shipped

I don't know how three years ago whatever it was and then all of a sudden I would plug in a device and then why a plumber exploded and I couldn't work out why I just ended up taking the folder renaming the folder to something that's not going to be loaded and then I'm going to deal with it later

yeah yeah exactly exactly that wasn't clear to the users It was hard. So, in the meantime, PipeWire developed this JSON-like configuration format that we have today. Which is, well, it's not standard JSON. It's a more simple version of JSON, but it can be parsed as a JSON. And you can provide also JSON files if they will be parsed by the same parser.

So it's something that also allows people who want to to develop tools for creating those configuration files. This can work with a standard JSON library. And that seemed like a very, very good idea. So you have a file that people can easily edit, but it can also be generated by machine code. And it was more easy to implement overrides. And as PipeWire implemented that and people started using that,

they started becoming familiar with that. It was a great way to do. configuration and overrides and basically I thought at some point, yeah, let's get over with the Lua config file. Let's use that. It makes sense. People already know how to use it. It has clear advantages to doing configuration. And then I did that. And of course that also confused people because now people were like, oh, but I thought we were done with Lua, but you still have Lua in there, right? Yeah, I kept the LUA scripting that didn't go anywhere, but we changed the configuration file. They were two separate, entirely separate things. Yeah. I do, when that update dropped, when the update dropped that went from Lua to, I guess, spar JSON, on, did, what was, um, did you get reports of things breaking, basically, did you get reports of people saying their entire wire plumber configurations just don't work anymore?

Yeah, of course. People always complain, right? When, when something breaks, they will come back and say, oh, you broke my setup. And of course, yeah, we broke, we broke a lot of setups. Um, And yeah, people were confused. They were expecting some migration tool to migrate their configuration, but that would have been really hard to write, actually, because everything changed in the configuration. The entire way of loading modules changed, the entire way of all the settings changed. It was impossible to go back and do a migration. or anything like that. Right.

How do you migrate a Turing Complete programming language to JSON? Yeah, exactly. It's not something that can be done 100%. You can approximate it. You can go and start part, like you can execute the Lua part and then see what it ends up with in options and then try to maybe migrate some of the options. But it's not something that will be 100% correct

because if you had added any, if-else structures there that depend on something else that wouldn't work and also not all of the options were one-to-one migratable right so yeah we broke a lot of setups some people complained some people were like cheating because now it was much easier for them to configure things and yeah that's how it went yeah having a having a complete programming language there as configuration language is it can work but you have to be very careful with it.

There are projects that are built around it and then there are projects which I think would do better if they didn't. I always think of the awesome WM window manager. It also uses a lure scripting language and it has a similar problem that wire plumber had where if

you get some syntax wrong, you put a structure in there that's not valid lure it just explodes. You just If you don't know Lua competently, it's very difficult to do more than just basic changes. And even then, basic changes can be complicated if you don't understand the structure, the files are supposed to have how the files linked together. And yeah, I rendered that problem a lot.

And I am very glad that it has gone down this route and it's considerably easier to use. So you're saying Lua is still used. That is still used in, what part was that still being used for with the scripting part? So that's for like policies. Yeah. Yeah. So basically the entire logic about what to do when events happen is written in Lua. Weirplumber is all events based.

So when, let's say, a new application connects, you basically get an event that a new client is there and then when this client creates a node and ports you get events about those objects popping up and what we have there in the scripts is we have event handlers where we can define exactly which event they handle and then there is code in lua that will take action based on that event and nowadays we have also this um hooks system where basically we can have multiple chunks of LUA code in different files that react to the same event and we can order them we can say this runs before that one and that runs after that one basically just like system the units that have to be that have to depend to one another and we yeah when an event

happens we take all the hooks that react to that event we order them and then we execute each one in order and we try to get through all of that before we execute the next one and that's the way that it actually works under the hood and that's how we make decisions about what needs to happen and then taking actions so when we are talking about configuring wire plumber there are there are the like simple things that i think a lot of people kind of know about like renaming your devices as an example. I have Starship Matisse HD Audio Controller Analog Stereo, which is a very useful name for my 3.5mm jack or my mixer board here, the MGXU Analog Stereo, or my favorite one. Navi 23, HDMI DP Audio Controller Digital, which again, that would be my HTML. Now, most

people kind of know that you can rename devices, you can disable devices, you just don't want to see. So as an example, I would usually have my HTML port disabled because I never listen to audio through my monitor. I will either use my speakers or my headphones. But what are some other interesting things you can do with the wire plumber configuration that may not be something a lot of people kind of know about yeah so well the basic principle is as i said you have all those events and you have all those hooks and what you can do is you can write your own hooks basically and if you if you if you know if you read the documentation if you figure out exactly the order of which other hooks run and you understand what they are doing then you can basically

put your own hook somewhere in the middle and change things as the script goes. So for example, yeah, the example that you brought is one of them, right? If you are, if a device is creating some nodes, then you can basically go and add some lua chunk there that basically changes the properties of that node before it gets created. So you can take the name and swap it with something else, right? this is one thing you can do well maybe there's maybe there's it's more it's a little bit more complicated than that for that particular use case but there are other use cases that work exactly like that so for example let's say you want to select a profile for your card with some

additional logic instead of having to select it on papu control you can very easily write a hook in LUA that will run just before the final apply function runs and then in there decide if you want to keep wire plumber's default or if you want to select something else based on your logic. Same thing with selecting default devices, same thing with linking. So if an application connects and wants to link somewhere, you can either let wire plumber take control and link it to the the default output or the defined target object that has been defined by the application or you can write your own hook inserted there and have it run its own logic which can be handy for some use cases like if you have things that you expect to be running a lot daily and

they are not being handled the way you like either because it says strange device that behaves strangely and you want to manage it in a specific way or because you have an application that behaves strangely and you cannot really change its settings internally and you want some other logic to be applied there. These kind of things. You can do easily with Lua scripts. That's the intention. And additionally, all the Lua scripts are being loaded by the configuration file.

So they are not being just loaded because they are in the directory. They are being loaded by the configuration file which defines components. There is a section called wire plumber. Components, which lists all the Lua files and all the modules. And by tweaking that, you can also disable certain hooks from being loaded. So you can say, okay, I don't want this kind of logic to be applied, so you can take it off. And then you have the rest of the scripts running without that one being loaded. it. Yeah, so that's the basic.

These are the kind of things that you can do with scripting. Now there are limits to that, unfortunately, we are starting to find the limits to where this can go nowadays with some more complex use cases that we have for specific devices. And we might have to, at some point, do another version where we even break things even further. So I've started thinking about, yeah, because even if you have an event that runs all those hooks, at some point it needs to take an action. So you have a new node being added and then you run a bunch of logic, but then you have to take an action. And then you have another node being added and you take an action. And there are a lot of cases where that action depends also on.

the things that are going to come after. So you have to wait. You have to defer the action until you have finished loading a set of things. And we currently do that with the linking policy. So if we see that a new node is being added, we are expecting that maybe more notes will be added. So we wait. We defer that action to later when the event loop is idle. But we are seeing more and more cases that this kind of separation is needed. And yeah, I'm starting to think that maybe we need to find a more generic way to separate actions from decisions. So take a decision here, put it in a queue, and then apply the action later.

And if a further, if a decision that comes later has to modify that action, take it off, replace it with another action, then we could also be doing that. Yeah, complex stuff, but it's what makes things work. We need to have a way to make informed decisions about what we expect, you know, the craft to be like. It's not easy, not easy at all. Even though you say it's not easy, I, we're at a state now, we're at least to the average user, things are kind of transparent.

And I think that's a good state to be in where unless you want to get like into the real technical weeds I think we're at a point where the transition over to pipe wire and wire plumber has been like it's at a point where it's smooth because I was there

that the like early start where wire plumber was not recommended yet where wire plumber was just barely becoming a thing that people were talking about and I remember it was there were some rough edges at the time

there were definitely some rough edges and at least now I have not had any major issues for a I would honestly say quite a long time a couple of years at this point and I would

imagine that most people are probably in a similar situation and any of the problems they do have are likely coming from some other part of the stack like Bluetooth is just, Bluetooth is Bluetooth. Bluetooth is, especially if you're in an area that has a lot of radio signals, right? Like, you're going to have problems.

Yeah, well, it's working though. Bluetooth is one of the things that I'm proud of in PipeWire that we have made it actually work for people instead of having them to fiddle with settings and whatever and not having all the codecs. Like in Pulse Audio, it wasn't the case that these things would work out of the box. And with pipe wire, if you are, well,

if you have interference, yeah, maybe that's a problem. But if you are, in most cases, people just don't have any problem with Bluetooth. It just will just work with any device, with any codec. It's just really good to have that working. And we are expanding. We are adding more features.

So we are working on Ellie Audio support, which is the new Bluetooth standard for audio. And there are some headsets that are starting to support it. And we have supporting pipeline for it already. Before even the devices are out, we had support for it. I'm really proud of that kind of proactiveness in that area. But yeah, there can be cases where people have problems, if they have strange setups or if they have um i don't know yeah things like interference things

like um just just something that's not not standard and they're trying to fiddle with it right and some people are like that by default like they they install pipe wire and they don't let it work as it is supposed to work they want to fiddle with it from the beginning and they say oh i want to configure this and this and that and they start touching the configuration file and then they break things but yeah that's that's human nature um and it's good that people actually have the ability to do it and they have the ability to um to add functionality as well to do more crazy things well being in the position you are where you actually are working through reports that people are making and all of this stuff how have you find or have you found sort of the

I guess reception of wire plummer changed because I'm assuming earlier on you were getting a lot of basic issues that were coming along where oh this obvious thing is broken this is broken but as the years have gone on how have you found that things have changed do you feel that people are generally finding weirder, more obscure bugs

as opposed to things that could have been there from the start Well, the first observation that I can make is that we have less and less reports about things being broken or, you know, problematic. Of course, we still have some reports. And most of the time, it's not easy to go through them and actually fix them. Like, there's, I actually don't have a lot of time to be able to. to be able to make meaningful changes, most of the time, right? But yeah, for some of the cases, like, we can look into them and try to go through.

Thankfully, we have contributors who are looking at things and they provide the patches and everything. Anyway, when we, I would say that the reports that we are getting today are, yeah, they're a bit more strange setups i guess or they are things that we already know they are problematic and people come up with uh like people report them because they are still struggling with certain things these can be coming also from different hardware different devices being used we are i know we're not doing a great job about handling UCM devices, for example. UCM being the ALSA use case manager, which is the new way,

the modern way of describing devices with, so ALALSA has this thing where, as I was saying, where in the beginning of this conversation, it basically exposes devices in a way that you don't see what they are, we don't understand what they are. And PipeWire tries to make up better user-friendly descriptions and separate the different inputs and outputs. But a lot of the time, it cannot do that without having some context of what the device is.

So it needs a little bit of context. And that context is provided in a configuration file, which in the past, we were using this configuration format that came from Palsodio. And in PIPWR, it's called ACP. It's ALSA card profile. And that uses Palsodio logic, so it creates devices in the same way as Palsodio was creating them.

And we are transitioning to UCM nowadays, where it's a standard way of describing devices directly in ALSA. So there's configuration files that ship with the ALSA libraries. And those configuration files describe the devices that we need to create on our site. And they are very different from what the Pulse Audio Logic was. So for example, in the Palsodio logic, we had a profile where we would be analog, analog output and input. And then if you wanted to switch to HTML, you had to select another

profile, which is HTML. And if you had multiple HTML ports, you would select HTML1, and every one of them was a different profile and for every profile the nodes of the other profile would go away so if you were switching from analog to hdmi the analog nodes would go away and then you would have hdmi right so you would only have one input output at a time with ucm it's not the case we create all of them at the same time if they are not mutually exclusive on the hardware level and it's usually the case that hdmi and analog have nothing to do with each other so that you can have them in parallel and output to both but depending on the device you can have all sorts of problems there with that representation and sometimes we come up with profiles to to mutually exclude

devices but they are obscure they have obscure names they have the switching also takes away the notes that you had before and recreates them sometimes like you have an analog output and you switch profile and the analog output is destroyed and then recreate it exactly the same way it was before. Makes no sense, but that's how we do it nowadays. And yeah, this can lead to problems. And also other kinds of problems that we, I know we have is the naming, for example. You said it yourself, like you're frustrated about the names that you have on your devices. And I completely agree. If I clip this section For anyone who is unaware of the device I'm talking about, open up pulse mixer or pavu control, you see what I mean.

Starship Matisse, HD Audio Controller, Analog Stereo. That's just one of my inputs. We can go to, one of my outputs. Inputs are just as actually inputs are worse, because then you have monitor of Starship Matisse, HD controller, HD Audio Controller, and I got a bunch of these. Yeah, um, they're not super useful names, a lot of cases. Yeah, they're very strange names and it's not easy to fix either because different classes of devices have different ways of representing their names and even on the same class of device sometimes you find discrepancies like USB cards typically have like some will put

the model in the description, some will put it in the name, some will put it somewhere else and you have to scramble to find which one is the model and which one is the um you know company name and which one is what there is no way to figure that out programmatically um yeah well actually one of the ideas i had there was well i don't know what if we could run a very small language model to actually parse that information and get the context of what is what i would be awesome but yeah I have no idea how feasible that is or it's something that we can pull off it's an experiment I would like to see the results of that it is it is yeah I'm also interested to investigate that but yeah it's it's a it's a problem like there is no solution there's no good

solution because the manufacturers of those devices don't follow a spec basically Yeah. I'm sure you've thought about this question a lot longer than I have. I don't think I can provide any insight into a better way to handle it. Yeah, like me neither. I'm just coming up with crazy ideas just to see what we can possibly do about it. Yeah. so what does your what does your background look like how did you find yourself at collaborer how did you find yourself working on audio stuff like what what brought you here um good question so yeah i started um i guess i started back in school i guess i was just curious with writing programs. I found myself trying my first Linux distribution out of a DVD that came with a magazine and it was saying Mandrake, Linux, something. And I was like, okay, what's that?

That's some kind of software. I have to install it because I was always a curious child. I was looking at, especially when it comes to computers, I was downloading a lot of software on Windows at the time and I was testing it and I just wanted to learn anything new that was out there so I installed that didn't understand how initially but yeah I installed that I broke my Windows setup obviously and I had to learn how to get through that and how to use it and I learned quite fast actually I was able to get back on the internet with with Mandrake Linux and find my way there and then I realized that you know this environment is open source that was a revolution to me I didn't know that this this was a thing right and what open source allowed me was to be

able to write my own code and contribute there and change things and make them the way I liked So I got into programming basically by playing with a software called Cute Designer. That was the cute toolkit designer that was allowing me to write user interfaces. It had a side thing where you could connect actions from the buttons to code and that code was written in C++. So I started learning C++ through C. Initially I learned C, I downloaded a book, I learned C. And then I, well, I started writing C in the C++ functions and started discovering what C++ is like, right?

I was finding the differences. And all of that was in school, right? I was still in high school. led me to computer science studies at the university University of Crete and while I was studying there I was still investigating this whole Linux environment thing and I started contributing to KDE because that came naturally after learning Q'd I was contributing to KD initially looking at bug fixes so I was I was basically the QA guy I was going through tickets and I was trying to reproduce them and give feedback to users.

But occasionally I would see something that looked like I could fix easily. So I started writing small patches as well and figuring out how I can make changes. And that led me in a Google Summer of Code project in 2009, where basically one of the guys that I was interacting with a lot on IRC at the time in the KD community he brought that idea to me and the idea was to write a video call client for KD at the time we were doing it was a huge thing to do telepathy that telepathy was a framework to unify all the instant Wait, um, did he disconnect?

Did I disconnect? What happened here? Oh, lovely. Hello. Yeah, it came back. Okay. Okay, this is going to be two of me for a moment. I don't know.

Yeah, um, so you're talking about, um, framework. telepathy. Yeah. So telepathy was the thing that was going to unify the protocols, the instant messaging protocols. And yeah, there were backend programs that were talking to the various protocols and at the front end we had a chat interface and then we were trying to write also a video call interface to be able to do video calls with, yeah. without, well, without using browsers, let's say, I think using browsers at the time wasn't that common, to be honest.

It was more that you had an application running on your desktop that was doing the call. Anyway, the idea was to write a video call client, and I started working on that. I took the Google Summer of Code project, and basically that taught me how to use GStreamer, which is a multimedia framework that I was using for actually doing the video presentation. processing, audio processing, and streaming. Mm-hmm. Mm-hmm. And I'm really sorry.

So there's a there's a home pot in the corner that I never use, but for some reason it decided to speak up right now. It's been time throughout the entire episode just now. Okay, sure. Yeah, so I learned G-Streamer out of that, and that's how I got into Collabora as well, because I knew G-Streamer, and actually the guy that was mentoring me was working for Collabora at the time, and there was, I guess I was lucky I was there in a moment where Collabora was trying to expand, and they were hiring lots of people. So, yeah, they hired me. And, well, shortly afterwards, like a year afterwards, telepathy pretty much died because Nokia died.

If you know the story of Nokia at the time, it was that they were building a phone, they were building a platform. And that was using telepathy, was using a lot of open-source stuff, but things were not working for them. internally and at some point they sold themselves to Microsoft and Microsoft killed everything and they said, okay, we're going to replace it with Wingo's phone, which also didn't work. So, yeah, so telepathy died and I had nothing else to work on at this at the time in Collabora

other than GStreamer. And so I dived more into that. And I was, like I said, from a small age, I was very curious about things. So when there was something that I didn't know well enough, I was curious to learn, whatever it was thrown in front of me. So G streamer was thrown in front of me basically, and I was seeing an opportunity to work there and make real money out of doing open source software. And it was just exciting. So I learned how to to get around with Gistramer and that's how I got into the multimedia team at Collabora

and that's also how I got into audio of course I did video I still sometimes do video stuff as well with Gistreamer but in uh well I was hired in 2011 and I was doing gistreamer all of that time but in 2018 as I got into the automotive grade Linux project, I started looking into pipe wire, and that led me into the whole pipe wire and audio work that I'm doing today. Okay. Yeah. That was, I like that. Yeah. That was a good answer. Yeah. It's basically my life story in a small description, I guess. so you've kind of just been involved in some way with it for kind of a long time now and I guess yeah now now wire plumber I guess how does it how does it feel that

wire plumber is basically it's basically the standard session manager across every distra at this point there's still a I'm sure there's still some random one out there that's using media session, and the distros which will always be doing whatever they're doing. But across, you know, Fedora, Ubuntu, Arch Linux, pretty much everywhere, it's wire plumber. Yeah. How does it feel? I guess it feels good to know that people use your software, but at the same time, I'm never satisfied with what we have, I think that it could be better.

It could be much improved. And even though it's being used, a lot of people just don't know it exists. Like, they use it in the background. They don't really care about it, right? And also, the people who know it exists, sometimes they don't know how to configure it, how to modify it. So that kind of defeats the purpose of it because it's supposed to be. something that is easily configurable and easily allows people to change things. And I see that not only on the desktop, but also on devices.

So occasionally I interact with customers that have already adopted pipe wire and wire plumber in their setups. And they are just doing everything wrong, right? They don't modify wire plumber, they don't write scripts, they basically built their own logic on top of it, or they do like, other things like using Palsodio APIs or JAG APIs to modify things on top, which basically side kicks wire plumber into just being the default that it is on desktops. Yeah, so, yeah, it, I guess, it feels, as I said, it feels good to have the software used, but I would like to, I would like to, I'm never, like, I'm never, like, I'm never resting that, you know, it's,

it's a good software or it's a good thing to have, like, it can be improved, can be better. Yeah. All right. Um, if people want to get involved in wire plumber and all this, what's the best way to go and do so? Well, the code is over there. You can just download it. You can look at the documentation.

We have a documentation website where everything is laid out for you. Well, if there is anything that people don't understand, there is always the contact channel through IRC or Matrix. I use Matrix myself, but we have a IRC bridge. The channel is the pipe wire channel, so pipe wire matrix.org. Or hashtag pipe wire in the, I don't remember which network. I think it's OFTC, but yeah, it's been so long that we haven't touched the bridge. Anyway, yeah, you can get in touch with us there if you need questions answered or if you need further ways to talk to me directly or some of the other contributors and obviously the code is

on a GitLab instance on GitLab freestop.org so you can submit merge requests there that's the best way to submit code submit the merge request or you can submit issues there as well if you are not confident on writing the code yourself you can submit an issue we can look into it and you can also file issues for support I'm not currently that it will be answered like if we have lots of lots of questions but a lot of people do actually open tickets for support and they say how do I do this how they do that and I try my best to answer those questions if I can if they're really easy to answer and

yeah but that's basically that's the I'm going to be disconnected. I don't think so. Oh. Hello? Yes, I can be back now. Disconnected for a moment. Yeah, I wasn't really saying anything.

I was saying, yeah. Okay, okay. GitLab is there. You go to GitLab, you submit merge requests. The code is there, documentation is there. That's about it. And the metric channel. Awesome.

Um, it has been a pleasure talking to you. I think it was a really good episode. Um, do you think there's anything, do you think there's anything we sort of miss that is worth touching on? Good question. Um, think back over the last two hours of talking. I don't think so. I guess not. Um, I, I, I, I don't think so. I guess not. Um, I, I, I think we've touched pretty much everything about pipe wire, wire, wire plumber, my backstory. Yeah, I can't think of anything. Okay, um, wire plumber docks.

Where are those located just for anyone who wants to go configure it? So the link is a bit obscure, but basically you can go to get Lumpur desktop dot org go to the wire plumber project and on the read me file which shows up on the main page there is a link there's a link to click and for the documentation ipewire dot pages dot free desktop.org i feel like somebody needs to maybe uh work on some work on some better URLs yeah i i actually have a domain i have both the domain uh wireplumber dot org but i i haven't been able to connect it i think i need support from just means there. Ah, okay. That's something on my

to-do list to actually get it to work. Just, um, if you can't do that, just set up an HTML redirect. That's good enough. Yeah, that should work, but yeah. Um, yeah. Is there any other links you want to mention? Um, I noticed you had a, you don't post a ton, but you do have your own personal site with some blog posts on it.

Yeah, my personal website is gkgatli.r. I can send you the link afterwards so you can put it somewhere. And of course there is the pipewire website, the pipewire documentation as well that is also very relevant. Something that maybe we haven't mentioned enough is that Yeah, a lot of people get confused about what is the borderline between pipe wire and wire plumber. And especially because the device plugins are maintained in the pipe wire project, but they are being loaded by wire plumber.

So they are being in two places at the same time. If you're looking at, let's say, Bluetooth options, you have to go to the pipe wire documentation to find what those options are, but then you have to write them in the wire plumber configuration file, which is a bit strange for people. I hope we can do a better job at clarifying that and describing that in the future. But that's how it is nowadays. If you are looking for documentation, sometimes it doesn't suffice to look at one place. You have to go to the other place as well to find what the options are and be able to write them.

And also when you are reporting bugs, it's also unclear at this point which component. Is it the wire plumber or is it pipe wire? Especially when it comes to device management, right? Because you might think that, for example, audio card profiles are being generated by wire plumber because wire plumber conceptually is the thing that manages your device. But in fact, it doesn't do anything besides loading a pipe wire plugin. The pipeware plugin is what actually implements that logic. And the ticket actually goes to pipe wire in that case.

But of course, yeah, it's hard for people to figure that out and know that from the beginning. So if you have an issue, just file it to the best project that you have thought of. It's relevant and then we can move it around. Okay, awesome. Nothing else you want to mention? No, I'm good. Okay. As I said before, pleasure to have you on.

This was a really good episode, and I'm glad that some random person who joined my Patreon just decided to connect us together. Yeah, I'm glad as well. I'm glad as well, and thank you for having me on the podcast. Yeah, absolute pleasure. Okay, so I'll do my outro, and then we'll sign off.

So my main channel is Brodie Robertson. I do Linux videos there six-ish days a week. Sometimes I stream there as well, probably going to do another cosmic stream at some point when they're another beta. I don't know. I'll think of other streams to do there as well. I've got the gaming channel that is Brody on Games.

Right now I'm playing through Yakuza 6 and Silk Song. And if you're watching the video version in this, you can find the audio version of basically every podcast platform. Just search Take a T and you will find it. and if you want to find the video, it is on YouTube Tech Over Tea. How do you want to sign us off? What do you want to say? I don't know.

Take care. This is my favorite part. I never tell anyone they're doing this. Yeah, well, yeah, take care. Happy using pipe wire, I don't know, something like that. Have fun with pipe wire and WordPress. Remember? Okay, that works.