The policy scripts can handle now client nodes that want to be linked with other
client nodes. This is needed for nodes created by the Pulse Audio Volume Control
to monitor audio comming from other application client nodes.
Not really a hard requirement, wrt libpipewire API, but it's
hard to keep runtime compatibility with earlier versions when
it comes to configuration options
Plugin() is confusing because it's not a constructor, it just finds
an existing instance of a plugin object. All other camel-case
functions are constructors in the current lua API.
This is no longer used and likely not very useful now that we have
a simpler design.
We can re-add it in the future if necessary, but let's keep it out
of the 0.4 release.
Also rename the intermediate lua api table WpDebug -> WpLog
Keeps things more consistent with the function names (wp_log*),
with the lua api (Log.*) and with pipewire using log.{h,c} as well.
After all, these functions are for logging...
Simple library that uses sockets for inter-process communication. It provides an
API to create server and client objects. Users can add custom handlers in the
server, and clients can send requests for those custom handlers.
After all, we can just load multiple lua config files/directories
from a single .conf file and so have both styles available for the
user to choose at runtime
These allow running multiple instances of wireplumber with
different config files. The config file is denoted on the service
name, ex: wireplumber@bluetooth loads bluetooth.conf
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.
