This patch removes the 'settings.persistent' option from the configuration as it
only allowed making settings persistent globally instead of individually. This
issue has been addressed in a simpler way by creating a 'persistent-sm-settings'
metadata. If a user wants to make a setting persistent, he can change the
'persistent-sm-settings' metadata object, if the user does not want to make a
persistent change, he can use the 'sm-settings' metadata object. Any changes in
the 'persistent-sm-settings' metadata will be also reflected in the 'sm-settings'
metadata object.
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.
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
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.
This reverts commit 2ae1b3cbd9.
This is not a good API. It was only allowed temporarily in 0.4.15
to get things done. We should approach this properly in 0.5
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.
