PipeWire Hackfest

So we kicked off the PipeWire hackfest in Edinburgh yesterday. We have 15 people attending including Arun Raghavan, Tanu Kaskinen and Colin Guthrie from PulseAudio, PipeWire creator Wim Taymans, Bastien Nocera and Jan Grulich representing GNOME and KDE, Mark Brown from the ALSA kernel team, Olivier CrĂȘte,George Kiagiadakis and Nicolas Dufresne was there to represent embedded usecases for PipeWire and finally Thierry Bultel representing automotive.

The event kicked off with Wim Taymans presenting on current state of PipeWire and outlining the remaining issues and current thoughts on how to resolve them. Most of the first day was spent on a roadtable discussion about what are and should be the goals of PipeWire and what potential tradeoffs there would be going forward. PipeWire is probably a bit closer to Jack than PulseAudio in design, so quite a bit of the discussion went on how that would affect the PulseAudio usecases and what is planned to ensure PipeWire works very well for consumer audio usecases.

Personally I ended up spending quite some time just testing and running various Jack apps to see what works already and what doesn’t. In terms of handling outputing audio with Jack apps I was positively surprised how many Jack apps I was able to make work (aka output audio) using PipeWire instead of Jack, but of course we still have some gaps to cover before PipeWire is ready as a drop-in Jack replacement, for instance the Jack session management protocol needs to be implemented first.

The second day we outlined the areas that need work before we are ready to replace PulseAudio and came up with the following list:

  • Mixers – This is basically dealing with hardware mixers. Arun and Wim started looking at a design for this during the hackfest.
  • PulseAudio services – This is all the things in PulseAudio that is not very suitable for putting inside PipeWire. The idea is instead to put them in a separate daemon. This includes things like network streaming, ROAP, DBus apis and so on.
  • Policy/Session handling – We plan to move policy and session handling out of PulseAudio to make it easier for different usecases to set their own policies. PipeWire will still provide some default setup, but the idea here is to have a separate daemon(s) to provide this. Bastien Nocera started prototyping a setup where he could create policy and session handling using Lua scripting.
  • Filters
  • Bluetooth – Ensuring we have great bluetooth support with PipeWire. We would want to move Bluetooth handling to its own daemon, and not have it inside like in PulseAudio to allow for more flexibility with various embedded bluetooth stacks for instance. This could also mean looking at the Linux Bluetooth stack more widely as things are not ideal atm, especially from a security viewpoint.
  • Device reservation – We expect to replace Jack and PulseAudio in steps, starting with PulseAudio. So dealing well with hardware reservation is important to allow people to for instance keep running Jack alongside PipeWire until we are ready for full replacement.
  • Stream Monitoring – Important feature from Jack and PulseAudio that still needs implementing to allowing monitoring audio devices and streams.
  • Latency handling – Improving ways we can deal with hardware latency in for instance consumer devices such as TVs

It is still a bit hard to have a clear timeline for when we will be ready to drop in PipeWire support to replace PulseAudio and then Jack, but we feel the Wayland migration was a good example to follow where we held off doing the switch until we felt comfortable the move would be transparent to most users. There will of course always be corner cases and bugs, but we hope that in general people agree that the Wayland transition was done in a responsible manner and thus could be a good example to follow for us here.

We would like to offers big thanks to the GNOME Foundation for sponsoring travel for some of the community attendees and to Collabora for sponsoring dinner for all attendees the first night.

If you want to take a look at PipeWire, Wim updated the wiki page with PipeWire build intructions to be up-to-date. The hackfest attendees tested them out so we are sure they work, just be aware that you want the ‘Work’ branch and not the Master branch, as that is the one where all the audio work is happening. The Master branch is the video focused branch we use in Fedora for desktop remoting support in browsers and VNC under Wayland.

5 thoughts on “PipeWire Hackfest

  1. Wayland is still full of regressions where e.g. you click on a link in a browser and nothing happens because the file you downloaded got opened in an already existing GEdit window on another workspace and there’s no Wayland protocol for an app to ask for attention/raise its windows. Or you enable the find-my-mouse-cursor accessibility setting and it doesn’t work because it was implemented as an external process and nobody rewrote it to do the drawing inside gnome-shell.

    And it’s fine, there are always bugs and regressions, but I get the impression that nobody is working on these regressions. The users who are affected do not have the technical chops to do anything about them, and the developers who could don’t seem to be interested?

    • We have dedicated people working almost exclusively on Wayland bug fixing. Olivier Fourdan for instance is constantly looking through Fedora, GNOME and Wayland bug trackers to find new issues that needs fixing. So if you file a bug in any of these 3 bug trackers and provide requested information we definitely try to fix them.

  2. I still don’t get why you should throw out a daemon that it took years to get working nicely and replace it with something else, for anyone looking from the outside this just seems like a giant waste of effort that makes it certain it will degrade the end user desktop experience for years to come.

    Why don’t you focus on integrating with PulseAudio instead of replacing it? I’m not sure I’m bying that this is an impossible feat.

    • Wim Taymans, the creator of PipeWire, has contributed to PulseAudio over the years, for instance the echo cancellation support in PulseAudio was done by him, so it is not like he is a PulseAudio outsider. And as noted in the blog post, the PulseAudio maintainers agree with his reasoning for wanting to move beyond PulseAudio and are here with us at the hackfest to plan for the work needed. Co-organizer of the hackfest is Arun Raghavan, PulseAudio co-maintainer. Another person who supports the plan is Lennart Poettering, the creator of PulseAudio. So while it is easy to jump to the conclusion that there must be a simpler way, I think it should also be clear that the people involved knows the field very well and that most of the involved people have spent years contributing to PulseAudio and thus would have strong reasons to want to keep it going if that seemed like a viable path forward.

Comments are closed.