This fixes a race condition that can happen when a proxy requests a new feature
(for example WP_NODE_FEATURE_PORTS) and PipeWire destroys the proxy before the
activation finishes. This race condition was causing the current activation
transition of a proxy to never finish, creating a memory leak because the
transition holds a strong reference of the proxy. Appart from this, since the
activation never finishes, WirePlumber could wait forever and not respond to
other requests.
This also removes the wp_proxy_watch_bind_error() API for subclasses as it is
not needed anymore.
If si_link fails to activate, we got an error saying
"attempt to index a nil value". This fixes the nil value problem
and also changes the warning to an info, since some of our badly
behaved apps can cause this and we don't see any problems resulting
from it.
When a pulse client connects with TCP, it is given the 'restricted'
access policy. Assign 'rx' permissions for those clients instead of
blocking forever.
See pipewire#1863
Consider invalid id as removed marker, similarly as in the preceding for
loop. This condition should currently not be possible to hit in
practice, but better to clean up.
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.
