This is a copy/paste from the code that now lives in apply-routes.lua,
but there is no point since the route here is a real route param and
not a route_info structure.
When a manual change is applied, the store-or-restore-routes is the only
hook that gets executed for this event. In order to be able to test if a
route was changed, we need to reset all of them to 'active = false',
record the previous value of 'active' and test their difference.
Testing only the 'active' variable (and discarding 'prev_active') sounds
tempting here, but if a route is changed back and forth (from A to B
and back to A), there is nothing to reset the 'active' variable of A
when it gets deactivated and it will appear as previously active on
the second switch.
Related to: #551
Add command for changing log level for Pipewire or Wireplumber daemons
at runtime.
It can be done with pw-metadata, but make it easier so that the user
doesn't need to look up Wireplumber client ids.
Pipewire server uses the global "settings" metadata for adjusting its
own log level.
Make it a convention that clients may watch "log.level" in this metadata
with their client id as subject, for setting their own log level
dynamically.
Watch the global "settings" metadata for "log.level" changes for our id.
On changes, set our log level accordingly.
Also:
- rename some files to remove redundant information from the filenames
- rename many labels to match the filename and its place in the hierarchy
- move lua_api under the scripting section
Previously the package version used for the gir file was hardcoded and did not change
when the `wireplumber_api_version` definition was changed, which has now been fixed to
use that definition.
* add a new common-utils method to get configuration sections with
defaults more efficiently and with less boilerplate
* rework the ALSA reserve-device settings so that the priority is
configured per device using rules and the application name comes
from the WpCore instead of the config file
* rename bluetooth to bluez in all options for consistency with other
monitors that use the backend API name
* rename alsa.midi to alsa-midi for consistency with bluez-midi
* rename settings to make more sense
* split out monitor settings into a separate category
* add setting for restoring the default nodes in the node category
It is possible that during this process some object managers emit
their "installed" signal, and it is possible that some object managers
are destroyed within the handler of this signal, ending up with a dangling
object manager pointer (since we do not ref object managers in the registry)
and with a modified object_managers list during iteration...
Related to: #534
Currently, if the adapter node already has its ports configured when wireplumber
starts (For example a virtual node), the async _set_ports_format() call is never
completed because the node ports have not changed, stalling the event stack.
This fixes the issue by checking the Props param after configuring the ports,
and completes the task if there is one pending and the node already has ports
available.
Fixes#527
This allows loading objects on demand by adding entries on the
"sm-objects" metadata object.
It is useful to dynamically load pipewire modules such as loopbacks
or network modules without having to start a new pipewire process with
a hardcoded config file.
It is also useful to load new metadata objects in order to implement
the singleton metatada concept as discussed in pipewire!1742
This may be expanded in the future to be able to load other types of
objects.
The key name, combined with the subject, is considered a unique id for
this instance of the object. The value should be a json object with
a 'type' specifying the type of object, together with a 'name' and 'args'
While handling endpoints, first check to see if there is a filter
intending to connect to it.
Also prevent Endpoints connecting to filters unless otherwise
configured.
