This reverts commit b6072f4179.
This is not right because when 2 nodes have the same name, there is
no way to know which one to use. It is better to rely on the
PW_KEY_STREAM_CAPTURE_SINK property when capturing from a monitor.
If we were linked before but our node is removed, wait until a new node
becomes available instead of failing.
This fixes an issue where there is only 1 sink available and the card
profile is toggeled between pro and stereo. After the profile is
toggled, the sink is removed and the node would be killed with an error
because there is no fallback sink. The fix is similar to the
pipewire-media-session logic.
This allows for WIREPLUMBER_DEBUG="D" which avoids users having to
remember which numerical value the various levels have. The strings to
select are the ones printed by the logger, i.e. UECWMIDT.
We're using the WpReserveDevice's name as key in the hash table, so we
must update the key as well when we replace an item in the hashtable -
the old device (and its name) will be released.
The side-effect of this is that the *third* device with an identical
name will no longer replace the previous device. This results in the
following sequence:
- dev1 added: name Audio0
- dev1 requests name owner Audio0
- dev2 added: name Audio0
- replace dev1 in the hashtable
- dev1 emits "release" signal
- dev1 unowns the Audio0 name
- dev2 requests name owner Audio0
- dev3 added: name Audio0
- adds to the hashtable because the existing key is now undefined
- dev3 requests name owner Audio0
- error, you cannot request ownership for the same name twice
Fixes#93
Remove the direction check in findDefinedTarget. We already to a
better direction check in canLink().
This fixes the case where a capture stream has the node.target set
to a sink. The directions don't match and the capture stream is not
linked to the monitor ports of the sink. Removing the check triggers
the right logic in canLink() and obs studio can link to monitor
ports again.
It's possible that we get multiple links on the same node, ex:
player -> output (output is the selected peer)
player -> pavucontrol
When pavucontrol exits, the peer_id of player must not be cleared,
since the link to the output still exists
-loop through all the linkable nodes, instead of using default nodes
-implement a priority scheme to pick the appropriate target linkables
-If both nodes support a passthrough format, check the intersection.
If the intersection is empty and one of the node is passthrough only,
skip the node as a target
-the logic now closely aligns with the media-session logic
Fixes#75
Once an object is removed from the registry, its id is invalidated and
can be later reused by other objects. WpGlobal objects may be
long-lived: e.g. those in tmp_globals may live over an add,remove,add
sequence for the same id, and a new WpGlobal must be used for the second
add. However, currently e.g. wp_registry_prepare_new_global may pick the
WpGlobal for a previously removed object from the tmp_globals list.
To address this, invalidate the WpGlobal id immediately when we get the
registry remove event.
Previously, we were always looking for the first available link on the item,
which could lead to problems if the item had more than 1 link (eg target and
monitor links). Now, we keep the Id of the last target in order to determine if
the item is linked to the proper target when rescanning.
When node.target is set to contain a node's name, it is possible to run
into the situation where you have a sink and a source with the same name
(typically the case with module-loopback) and the sink has monitor ports,
so wireplumber may link the stream to the monitor of the sink instead of the
capture ports of the source
With this policy, if a stream really wants to link to the monitor of the sink,
it has to have the "stream.capture.sink" property set or specify the
target by id.
If one link fails, the activation transition will return, but then
other links will continue to call the callback and try to access
the now invalid activation transition. With this change, the callback
is bound to the lifetime of the transition and will stop being called
after the transition returns
Fixes#76
There is a chance of race condition here in case the client knows which target
it wants to link to, but wireplumber has not yet "seen" this target because
it is getting prepared asynchronously
This may stall for up to 2 seconds clients that start streams with an invalid
node.target property, but then they will be re-routed to the default node
If the item was not already handled or if there is no target,
we don't need to search for existing links... we will not find any
Also, don't remove links or schedule rescan if the node is not eligible
for reconnection... we will delete the node below instead
