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
This patch fixes the policy to not link the client to the default filter if the
client's defined target is found, is not a filter, does not have any other
filters linked with it. In this case, the client is therefore linked to the
actual defined target. On the other hand, if the client's defined target is a
filter, the client is linked to the first filter in the chain that has the same
target as the defined filter's target.
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
