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 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
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.
Note: this requires all existing config files to be modified to follow
pipewire's rules syntax, with an "actions" object wrapping the
"update-props" object.
When set to 'true', the node will remain alive without any error produced if
it cannot be linked to its specified target; in all other cases, an error will
be produced and the node will be destroyed.
Two new properties are available to change the behavior of the linking policy:
- target.dont-fallback: when set to true, the node shouldn't be allowed to
fallback to another available target other than the one specified in the
target.object property or metadata.
- target.dont-move: when set to true, wireplumber should ignore the
target.object metadata, so that it isn't possible to dynamically move the node
to another target using metadata.
See #524
some hardware devices are never supposed to be accessed directly by
clients, and are designed under the assumption that they will be
front-loaded by some sort of DSP. add a hide_parent property
to policy-dsp and revoke all permissions to the bound node of a DSP
graph where this is set to prevent hardware misuse or damage by poorly
behaved/configured clients.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
This patch improves the smart filters unlinking logic by only unlinking smart
filters that are disabled, instead of any kind of filters. The patch also
removes redundant filter hooks.
