This configuration allows splitting wireplumber into multiple instances.
The "main" instance takes care of loading and managing devices
The "policy" instance does all the linking and implements endpoints
The "bluetooth" instance runs the bluetooth devices & nodes
Test with (in separate terminals):
./wp-uninstalled.sh -c config-split -- wireplumber -c main.conf
./wp-uninstalled.sh -c config-split -- wireplumber -c policy.conf
./wp-uninstalled.sh -c config-split -- wireplumber -c bluetooth.conf
This allows configuring:
* the scripting engine, in case we ever add another one
* the app name, so that we can distinguish multiple instances
of wireplumber
* the log level in the same way as pipewire
* wireplumber components to load. This allows loading components
even without a scripting engine (for a mimimal daemon) and also
allows configuring which lua config file(s) to load
* additional pw_context properties that pipewire modules may be using
* the exact pipewire modules to load (instead of relying on client.conf)
And don't override PIPEWIRE_DEBUG, unless WIREPLUMBER_DEBUG is set.
This allows pipewire to use log.level as well to set up its logging.
If WIREPLUMBER_DEBUG is set, though, override PIPEWIRE_DEBUG to prevent
log.level from being used.
This allows the channelVolumes and mute props to affect the output
of the null sink's monitor ports. This way we will be able to use
channelVolumes to track the configured volume of the endpoint
and the monitorVolumes to implement volume ducking.
This fixes adjusting volume for bluetooth nodes.
Previously, the spa device would request a software volume change
that we did not handle because WpImplNode was not a WpPipewireObject
and there was no way to set the Props param on it.
These don't make much sense here. In the endpoint policy we want
the clients to be linked to the endpoint that matches their role
and never move.
Also, endpoint priorities are useless. If no endpoint matches the
role, then just ignore the client.
This allows closures to be properly unrefed when they are no longer
used instead of staying alive until wireplumber exits
Because GClosure has no weak references, we are now sharing the
GPtrArray that holds these references among all the active closures
and each closure is responsible for removing itself from the array
when it is finalized. The lua engine holds a reference to a "store"
object that also has a pointer to the array and when this "store"
is finalized, all closures are invalidated and removed. Even if they
stay alive afterwards, they are only holding a ref to an empty array
This is mainly for security reasons. This way, we can limit the
permissions of wpexec without limiting wireplumber, for instance
with pipewire's default module-access, which limits apps based on
their executable name
This function loads and enables "api" plugins and makes them
available in the specified callback. This is intended to be used
by interactive scripts in order to get access to "api" plugins
such as the new "default-nodes-api" and "mixer-api"
This module provides an API to get/set volume controls on nodes,
using the same logic as pipewire-pulse, which means it will use
the device Route props when a node is associated with a device
that has this capability
