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.
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
