The Role traversal of config data to take notice of the
media class as well so that source and sink roles dont
overstep on each other and pick up unexpected endpoints.
This is expected to be printed if a stream opens and closes
very quickly, like in the case of pipewire-alsa opening the device
for querying formats and then closing it immediately.
If the default nodes module is loaded, and the default node is not found, it
means that there is no valid target for that session item. We only need to
manually find a default target if the default nodes module is not loaded.
Fixes the warning:
[string "policy-node.lua"]:117: attempt to index a nil value (field '?')
stack traceback:
[string "policy-node.lua"]:117: in function <[string "policy-node.lua"]:109>
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
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.
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
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.
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
This is now done by the metadata implementation.
Doing this manually causes assertion failures, because then the
target.node is removed before policy-node "unhandles" the associated
session item and it tries to re-link it to the default source/sink
