This patch improves the bluetooth profile autoswitch so that it works with any
application that wants to capture from a bluetooth device. To do so, a loopback
source filter is created per connected bluetooth device. If an application wants
to capture audio from such loopback source filter, the profile in the associated
bluetooth device is changed to HSP/HFP. If there isn't any application connected
to the loopback source filter, the profile switches back to A2DP.
The 'target.dont_move' property is only meant to be used with 'target.object'
metadata property, not smart filters metadata properties. This was probably
left accidentaly unused when designing a solution for #524 involving smart
filters.
Fixes#558
This property indicates whether the filter can be directly linked with clients
that have a defined target (Eg: pw-play --target <filter-name>) or not. This can
be useful when a client wants to be linked with a filter that is in the middle
of the chain in order to bypass the filters that are placed before the selected
one. If the property is not set, wireplumber will consider the filter not
targetable by default, meaning filters will never by bypassed by clients, and
clients will always be linked with the first filter in the chain.
Fixes#554
* 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
* 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
* 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
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
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.
This patch updates the deprecated policy-bluetooth.lua script so that it works
with the current version. The script has been moved into the device sub-folder,
and renamed to autoswitch-blueooth-profile.lua. The settings-manager is also
used for the configuration, and the actual configuration has been moved from
linkind.conf to bluetooth.conf.
This allows users to enable/disable smart filter policy per filter. The property
is considered false by default, meaning that smart filter policy is disabled for
all filters by default.
I don't fully remember where this originates from, but it looks like
some sort of hack to workaround a race condition where the event handler
would try to iterate over items that were just created and were not yet
fully ready to be used.
The filter's destination target was not being found properly due to iterating
the matching rules table with ipairs instead of pairs... the later is meant to
be used with JSON objects. In addition, the filters were not being re-evaluated
and linked properly when a device node was removed, this is because of a typo in
the find-best-target.lua script.
See #501
This removes both the policy-virtual-client.lua and policy-virtual-device.lua
scripts, and creates a new linking/find-virtual-target.lua script to link
clients with virtual session items if one of them can be found. In addition to
this, this patch also ports the policy-virtual-client-links.lua into a new
scripts/rescan-virtual-links.lua to use the event stack. The idea is for the
scripts/link-target.lua to create all links but only activate non virtual links,
and for the scripts/rescan-virtual-links.lua to activate/deactivate virtual
links based on role priorities.
This patch also moves nested configuration objects that are not considered
settings from the wireplumber.settings section to its own configuration
section (eg the rules array, the spa plugin properties, etc...). This allows
those objects to be merged with other same sections defined in other files.
Use the directory name and file name to construct the hook's name,
like a path. This way, when you see a hook name, it is clear where
to find that hook in the source code.
* Use more hooks and no custom object managers
* Use the settings manager for the config values
* Allow fully disabling the hooks when both restore-props and restore-target
are disabled in the settings
* Change the format AND the name of the state file; use json directly
in the values now that we can
It is better to have type-specific event names to minimize the amount
of constraint string matches we do on hooks, as most hooks (if not all)
are interested on specific types of objects only.
Similarly, use a different object manager for each object type to
minimize the performance impact of iterations and lookups, as all
such actions are interested in only 1 object type every time.
Port all existing hooks to the new event names and the get-object-manager API.
