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.
* 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
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.
Equalizer Node or filter nodes are considered as regular linkable and
its output is connected to endpoint. Prevent this by skipping over
filter nodes in this script.
This is a behavioural change in effect since pipewire 0.3.68, where
pipewire's link-factory ignores the link.passive property and the
node.pasive = in/out/true is used instead.
* prefix all settings with just "linking."
* rename settings to make more sense
* fix the handling of the "follow" setting
* move the "move" handler to the rescan.lua script, as it's just a rescan hook
The "follow" setting was never really meant to disable reacting to
default target changes. It is also not meant to disable moving normal streams
to follow the default target. It is only meant to control whether streams
with a 'target.object' that matches the default target will move or not
to follow the default target changes (PulseAudio compat thing...)
Even if we leave this code here, disabling the "follow" option may disable
reacting to default target changes, but the streams will be moved anyway
when there is some other change in the graph (i.e. in the next rescan)
* prefix all settings with "node."
* move settings-stream.lua to settings-node.lua
* move the "audio-no-dsp" setting to the node settings
* add more settings related to node features
* split the default stream volume into 2 settings, one for playback
streams and one for capture streams
The vm.node.defaults logic which was inherited from p-m-s is not really
good because it seems like different VM hardware requires different
values for the defaults. Also, passthrough USB hardware should not
inerhit these values, they just cause trouble.
Instead, we can use rules to match the vm.type and specific device
properties to set a more informed period & headroom.
For now, I am also decreasing the default headroom down to 2048, which
works for me and perhaps it's a good default. We can always add more
rules here and fine-tune per vm type and virtual hardware.
See !394, #316, #348, #507, #162, pipewire#3452
This is a new rules section that allows defining rules to modify
component definitions. This is useful to add repetitive dependencies,
for example, as in the case of "type = script/lua" that always requires
the "support.lua-scripting" feature. This can also be useful to modify
other component properties, such as the arguments, in overriding
configuration files, without needing to redefine the whole components
section.
The previous naming convention was confusing because it did not make
it explicit that the string is not being copied. We had this wrong already
in the Lua bindings and thanks to some miracle it hasn't backfired so far
(it was using the "wrap" behaviour with a string that doesn't stay alive).
In some places we actually need the "copy" behaviour and in some other
places we need the "wrap" behaviour, so let's have both variants available.
Do not continue iteration over all other profiles when
we found the profile set in the 'device.profile' property.
In other case we would overwrite this profile when
we find a best_profile.
