This patch removes the manually created object managers in the BT profile
autoswitch logic, and instead uses the object managers from the event source,
simplifying the logic a bit.
The intention here is to fix a Bluetooth bug where changing between different
profiles momentarily causes streams to be linked to an internal speaker.
Unfortunately, this case is not handled by the event dispatcher because some
signals are emitted using idle callbacks, and therefore we have to rely on
extra logic in rescan.lua to solve the problem.
This reverts commit 8012fbd5cf.
There seems to be some underlying bug that sometimes causes a crash
when the Bluetooth monitor uses a loopback for autoswitching between
profiles. Reverting temporarily until the cause is fully determined.
See #682
The previous assumption that any target with "device.intended-roles"
should be managed by the role-based policy is wrong, as for example
Bluetooth SCO nodes always have "device.intended-roles = Communication"
and some ALSA devices managed by ACP also do. This is meant to be used
as a hint for the desktop policy (it's been there in PulseAudio as well)
and does not necessarily mean that a role-priority-based policy should
be applied on all links to those devices.
Instead, use a new property to explicitly mark all the targets that
are meant to be managed by the role-based policy and respect that in
all places where we check for a potential role-based policy link.
Fixes: #682
This way of definining dependencies ensures that if we remove one
of the find-* hooks from the config, the rest of them will continue
to work in the expected order. Previously, removing one of them
would break the entire chain.
Also, move the example from linking.conf to media-role-nodes.conf,
as it's more relevant there, and make sure the setting is constantly
read back in the Lua script, so that runtime changes can work.
There are 2 cases captured here:
1. The stream has "stream.monitor = true", which is used
by pavucontrol for the vu meters and should probably not be managed
by the role policy, no matter if the target is a Source or a Sink
2. The stream is an Input (capture) stream and is targeting a Sink,
which may be used to target the sink's monitor ports. Even if we
want, we can't manage these links because they have opposite direction
than the one expected. Let's leave them alone...
First, add the find-media-role-target to the standard policy.
It does not affect anything and it doubles as the replacement
for intended-roles.lua, as it merely prioritizes linking nodes
that have "media.role" set to targets that have "device.intended-roles"
set to the corresponding role.
Second, make the rescan-media-role-links.lua also load as part
of the standard policy. The idea is to embrace this functionality
by default and make it available on desktops. It does not break
anything as well, but it will apply its own rules to links that
are created between nodes that have a
"media.role" <-> "device.indended-roles" match.
Regular filters should be treated as regular stream / device nodes. Note that
the filter utils API is meant to be used using the direction of the main smart
filter nodes. This is why we use the target direction instead of the actual
stream direction to check if the stream session item is smart or not.
This should never happen, but there are odd cases with broken
configuration where such a device may appear and the least we can do
is not crash, at least not when the device.name is only used for
debug messages. In state-profile and other places where the name
really matters, we actually have checks in place.
Fixes: #674
We always have to destroy the restore timeout source when we want to switch to
HSP/HFP profile, even if the device is already set to HSP/HFP or has already an
input route. Apart from this, we also want to make sure there is no pending
timeout source when we are creating a new one. This should avoid an infinite
loop about switching BT profiles when capture nodes are created and destroyed
quickly.
Indexing into the subject from a node-removed event is slightly quirky.
As a result, we were not properly freeing filter chains tied to
disconnected nodes.
Change how we store the list of loaded filters and ensure they
are properly freed when their parent node is removed from the graph.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
If a source filter is used, the BT profile autoswitch does not work because
WirePlumber thinks there is always a client capturing audio from it. This patch
fixes the issue by recursively walking through the source filters that are
linked to the BT loopback source until a stream is found. If a stream is found
at the end of the chain, then it switches to HSP/HFP profile, if the stream is
not found, the profile stays to A2DP.
With this change, it is possible to have a top-level object that does
not start at exactly the beginning of the file, allowing comments and
whitespace to exist.
Also add an empty conf file in the tests to verify that
it does not crash.
- split merge.conf into two files, one being standard JSON,
to ensure we can parse this
- ensure that key-value pairs are correctly overriden when
merging without the override. prefix
- remove context.modules, which is no longer needed there
- fix a typo with a stray ; character
