`wp_object_manager_add_interest()` passes the format string
and the arguments after that to `g_variant_new()`, which
requires a 32-bit integer for "u". Passing a 64-bit integer
will cause problems on certain ABIs.
Furthermore, remove the metadata related interest declaration
from `set_default_prepare()` since the "set-default" command
does not access metadata directly, it uses the "default-nodes-api"
plugin.
Fixes: 7784cfad92 ("wpctl: support @DEFAULT_{AUDIO,VIDEO}_{SINK,SOURCE}@ as ID ")
Fixes#773
stream-restore should not be touching node properties of the Bluetooth
mic / device set / offload / ALSA UCM split loopback nodes. Those are
controlled by Route settings on the device.
Set device.routes and state.restore-props=false as appropriate to avoid
that.
Instruct ACP to provide information about UCM SplitPCM channel
splitting instead of doing it with alsa-lib plugins.
Use the provided information to load loopbacks that create virtual sinks
that do the channel remapping from UCM.
Node name deduplication relying on presence of node objects creates race
conditions, as the name cannot be marked unused if the node object was
not created or was destroyed.
Use separate (device_id, node_id) -> name table to track name ownership
separately from the existence of node objects.
Also clear up the reserved names when device is destroyed, by the
monitor or device reservation. In these cases "object-removed" for
nodes is not called, so this fixes names leaking when e.g. pw-reserve is
used.
In cases where a Node is created asynchronously and associated with the
Device later, set the id pending so that we don't miss ObjectConfig
events.
The "set Route again" workaround is also not needed, moreover it was not
reliable before either since the Device might issue ObjectConfig only
for changed properties.
If loopback is emitted after the SCO node, e.g. when A2DP profile
connects late, recreate the SCO node.
This ensures the underlying SCO node is hidden when the loopback is
present.
This seems to be an omission from when we transferred the default device
properties from the config file on to the Lua script. Both auto-profile
and auto-port are meant to be disabled, so that we can apply our own
management logic.
Fixes: #734
When node activation fails, it won't be created and its object-removed
signal can be called with some properties missing. This breaks node
name deduplication, causing error
wplua: [string "alsa.lua"]:182: attempt to concatenate a nil value (local 'node_name')
It occurs e.g. when switching ALSA device profile, while some
application has opened the device with ALSA and is keeping it busy.
Fix by handling the activation failure, and tolerating missing property
in object-removed.
This patch adds a 500ms timeout callback to switch to HSP/HFP when a stream
starts capturing BT audio. This avoids quickly switching from A2DP to HSP/HFP
back and forth if an application just wants to probe the BT source for a short
period of time.
See #634
The actual deduplication only checked the first device. Extend it to the
full list, as intended.
Fixes: 848b6326 (monitor-utils: Rework camera deduplication code)
The previous code made some invalid assumptions and was rather
complicated. Rework and simplify it.
The approach work as follows:
1. Once a new device gets registered, store its data in a list of pending
devices.
2. Start a timer. On timeout, we check all pending devices and depulicate
according to our heuristic. The timer gets reset whenever a device is
added in order to avoid race conditions.
3. On timeout, add the pending devices to categories. For now: UVC cameras
from the V4L2 plugin, libcamera cameras and other cameras from the V4L2
plugin.
4. Then process the different categories in order of preference and store
their V4L2 device IDs in a list for each plugin.
5. Before creating a camera, check that the V4L2 device(s) it uses are not
yet used by a already existing camera from the other plugin.
While on it, drop support for Pipewire versions that don't report V4L2
device IDs at all.
Closes https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/689
Closes https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/708
Handle only devices associated with Bluetooth loopback nodes.
Make sure the node.link-group iteration cannot get stuck if there is a
loop in the link graph.
Revamp the profiles section, making use of the inherits feature
and add commonly used profiles for systemwide & embedded use cases,
as well as profiles for a split-instance configuration where the
policy hooks run in a separate instance from the alsa, bluetooth
and camera monitors (which run in 3 separate instances respectively)
Also add an example on how to configure the loaded profile using
a config file instead of the CLI switch.
Fixes: #608
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.
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.
