I think my previous posting of this wasn’t thread-appropriate, or just barely. Anyway! Pipewire is still interesting to me, I still haven’t tried it out yet except for mundane stuff on a work computer. (And still works great for that.)
Pasting what I wrote below but I’m pretty excited about something from redhat/fedora (I mean, they have made a lot of lovely and stable/ongoingly-supported stuff for linux in the past, like probably all the stuff about gnome you like and also other new exciting stuff like flatpak) that intends to replace/improve-on both pulseaudio (which is a pile of good intentions that I as a rule uninstall immediately if I want to do music work on linux) and jack which is kind of crazy…
They shipped the audio portion of it in the latest fedora ahead of any of the video stuff, I think at the moment the only released parts of pipewire are the audio components! I know it’s intended to do lots of wonderful realtime stuff, and from the stuff I’ve read they intend to support low level interfaces for developers to use as well – “graph based processing with support for feedback loops and atomic graph updates” seems like they have ticked the boxes i’m aware need ticking for that sort of thing
Um, but! Still I’ve only done basic day-to-day audio stuff with it personally so I can’t speak to any of that from experience yet. Okay well now I think I know what I’m going to try to fuck with tonight. :-p
Arch linux already has an offical package for pipewire – installing suggested I can install ffmpeg, libva and jack2 as deps which is interesting and makes me think pipewire may work WITH jack2 which would be amazing.
Created symlink /etc/systemd/user/sockets.target.wants/pipewire.socket → /usr/lib/systemd/user/pipewire.socket.
Optional dependencies for pipewire
PipeWire is a server and user space API to deal with multimedia
pipelines. This includes:
- Making available sources of video (such as from a capture devices or
application provided streams) and multiplexing this with
- Accessing sources of video for consumption.
- Generating graphs for audio and video processing.
Nodes in the graph can be implemented as separate processes,
communicating with sockets and exchanging multimedia content using fd
Ah also some tidbits in a design txtfile in the repo:
PipeWire is a media server that can run graphs of multimedia nodes.
Nodes can run inside the server or in separate processes.
Some of the requirements are:
- must be efficient for raw video using fd passing and audio with
- must be able to provide/consume/process media from any process
- policy to restrict access to devices and streams
Although an initial goal, the design is not limited to raw video
only and should be able to handle compressed video and other
media as well.
PipeWire uses the SPA plugin API for the nodes in the graph. SPA is
a plugin API designed for low-latency and efficient processing of
any multimedia format.
Some of the application we intend to build
- v4l2 device provider. Provide controlled access to v4l2 devices
and share 1 device between multiple processes.
- gnome-shell video provider. Gnome-shell provides a node that
gives the contents of the frame buffer for screen sharing or
- audio server. Mix and playback multiple audio streams. The design
is more like CRAS (Chromium audio server) than pulseaudio and with
the added benefit that processing can be arranged in a graph.
- Pro audio graph processing like JACK.
- Media playback backend
The native protocol and object model is similar to wayland but with custom
serialization/deserialization of messages. This is because the datastructures
in the messages are more complicated and not easily expressable in xml format.
The functionality of the server is implemented and extended with modules and
extensions. Modules are server side bits of logic that hook into various
places to provide extra features. This mostly means controlling the processing
graph in some way.
Extensions are the client side version of the modules. Most extensions provide
both a client side and server side init function. New interfaces or new object
implementation can easily be added with modules/extensions.
Some of the extensions that can be written
- protocol extensions: a client/server side API (.h) together with protocol
extensions and server/client side logic to implement a new object or
- a module to check security of method calls
- a module to automatically create or link or relink nodes
- a module to suspend idle nodes
Oops, um I feel like an idiot. So I got to the end of that article and it said “video only for now!” and I swear I read the opposite when it was announced on LWN, but clearly I’m just an idiot. All this time I’ve been using my little default install of fedora at work thinking “gee audio works fine!” but it’s probably pulseaudio haha. Pulseaudio always was totally fine for that sort of thing. Anyway! Derp. I guess the audio layer ISN’T out, they shipped video first.
Well, finally something somewhat tangible on the sound side of things
Also, like @lazarello said, I’d be interested in what they are trying to do that JACK doesn’t already do? What’s the reason it exists and can/should replace JACK?
AFAIK no one working on pipewire has been in touch with any of the JACK devs, make of that what you will, but at the very least that’s a missed opportunity.
To play devil’s advocate, the situation with jack & jack2 existing side-by-side, and the process of starting a Jack server alongside whatever Jack-enabled applications are desired seems like a stumbling point for new users, so if pipewire is transparent to new users, but also supported Jack, that seems like a win-win.
Generally though, I think their major goal is a system that has tight integration between the video and audio layers? From the blog post:
Another important goal of PipeWire was to bring all Linux audio and video together, which means PipeWire needed to be as good or better replacement for Jack for the Pro-Audio usecase.
Someone msgd this CPU usage chart to #lau yesterday, and I had yet once again managed to not turn my external DAC on before login to my [newly] JACK-first desktop, so I made the dive using the audio system drop-in packages on Arch Linux.
I had tried 9 months ago but it was too much pain, like moving to swaywm from i3 was several years ago, but things are apparently mostly working out ok now. Slight problem displaying CV ports, but I mentioned it in #lad and wtay and falkTX got on it. N.b. #pipewire on freenode is a very active channel atm.
Teething problem; everything currently autoconnects to a loopback output rather than my main DAC, but I’ve yet several PW related tabs to work through and further searches to do. Curious as to how the current session management system works. I have been using NSM/Agordejo for JACK wrangling.
Also wondering how far along the SPA plugin concept is and how it relates to or could relate to the functionality of LV2 and JACK (like metadata and CV).
In case anyone else is using pipewire with arch linux, and potentially had previously installed the pipewire-jack-dropin helper from the AUR – here’s the upgrade process that worked for me this morning:
If you try a system update and pacman complains that jack2 is in conflict with pipewire-jack you might need to remove the pipewire jack packages first, then reinstall.
Remove pipewire-jack-dropin (it has been removed from the AUR): pacman -R pipewire-jack-dropin
Remove pipewire-jack (you’ll install it again in a moment): pacman -R pipewire-jack
Upgrade your system: pacman -Syu
Reinstall pipewire-jack: pacman -S pipewire-jack
On this final step, when pacman asks if it should remove jack2 because it is in conflict with pipewire-jack, say yes to remove it and use the pipewire jack support instead. I also had to uninstall jack2-dbus and a single program that depended on it which I never use… I can’t remember what, one of the many jack patchbays I think.
Anyway, that’s it – things seem to be working OK again for me after removing jack2 completely.
(Since switching to pipewire last year I’ve been quite enjoying the experience FWIW.)