Pipewire is an audio and video server designed around pipeline, and the standard on desktop systems nowadays. WirePlumber is its default session manager. It has a 0.5 release coming sometime this year.
Pipewire is meant to replace pulseaudio and jack. It includes an emulation layer so legacy applications work out of the box. Low latency is core to its design, this is realised around how buffers are handled. It has excellent performance in general, which is essential for video of course. It has a very modular design around graphs of objects. The architecture consists of many parts that work together to achieve all the features. Security is built-in, with permissions for accessing objects. There are many tools built around pipewire.
One of the pipewire components is the session manager. It enumerates all of the objects. It creates the objects corresponding to audio and video input and output devices. The session manager creates the routes in the hardware. It defines the access permissions. It has a native session manager, but nowadays the default is to use an external one, wireplumber.
libwireplumber provides a higher level API above the pipewire API. It’s GObject based. WirePlumber daemon runs on top of this API and does the session management. It runs modules and Lua scripts – all the libwireplumber API is available in Lua.
Pipewire moves to SPA-JSON (Simple Plugin API) for configuration. With this, wireplumber will gain configs that can be created dynamically and can easily be overridden. They’re automatically persisted.
When something changes, e.g. a bluetooth device is connected, a pipewire signal occurs. Wireplumber cannot prioritize these signals, or between handlers of the signals. E.g. it’s possible that the new device comes up in A2DP; if there’s a videoconf application running, it should switch to HFP. However, it’s possible that the handler that creates the A2DP nodes runs first, and the later switch to HFP destroys them again. Wireplumber 0.5 will solve this by adding an event dispatcher. This will collect all the hooks first before calling them. Priorities can be assigned to the hooks as well as to events themselves. The dispatcher will run them one by one according to priority. If one of the hooks creates a higher-priority event or hook, that one will run first (i.e. it’s a kind of pre-emption).
The new hook-based system (instead of event handlers) makes the system scripts much more manageable. Wireplumber used to have a very complex policy system script, but that is now broken down in separate hooks.