Spamming wireplumber's wp-event-dispatcher ... failed ...link failed: some node was destroyed before the link was created

[C0rn3j]

Repro possible with python's playsound library, or more directly with gst which it uses:

1. pwvucontrol
2. journalctl --user -efu wireplumber
3. gst-launch-1.0 -v playbin 'uri=file:///home/c0rn3j/Nextcloud/HugeFiles/Music/Alissic - bugfood/01 - bugfood.mp3'
4. See the log:

Sep 30 19:46:47 Luxuria wireplumber[2630621]: wp-event-dispatcher: <WpAsyncEventHook:0x5bc5428b1c40> failed: <WpSiStandardLink:0x5bc542e325a0> link failed: some node was destroyed before the link was created

pavucontrol&pavucontrol-qt suffer from the same bug, but they do not handle the stream errors/readiness at all, so they bug out severely as per https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues/154

gst somehow creates multiple sinks I suppose?

Maybe pwvucontrol should wait a couple miliseconds before creating the link? Maybe it's a gst bug that should ALSO be fixed?

I have no idea.

This ends up spamming my wireplumber log badly, as the line can trigger multiple times per played file.

[saivert]

I only see it happening with gstreamer's playbin. If you pass it to the pipewiresink directly like:

gst-launch-1.0 uridecodebin 'uri=file:///home/saivert/Music/mp3/Royksopp - Profound Mysteries/01. Royksopp - [Nothing But] Ashes....mp3'   ! pipewiresink

Then there is no error in the log.

[C0rn3j]

I am originally first hitting this through playsound -> https://github.com/TaylorSMarks/playsound
Should they ideally add pipewire support and just use that when available instead of playbin?

Is this a bug on the side of pavu/pwvucontrol, or is this somehow a gstreamer bug and it should be reported at https://gitlab.freedesktop.org/gstreamer/gstreamer/ ?

[saivert]

Seems like gstreamer's pulsesink does some probing which causes errors like: wp-event-dispatcher: WpAsyncEventHook:0x55c9a1b79bc0 failed: WpSiStandardLink:0x55c9a1e813a0 link failed: some node was destroyed before the link was created -- As soon as the probe stream is created pavucontrol tries to record from it for the peak meter and then the node is gone by the time wireplumber is linking it up.

Yes delaying the setup of the capture stream for peak metering will solve this but I feel it is wrong to put workarounds here. This is something wireplumber should handle and if not nudge offending API users into behaving better (why probe at all?).
Audacity is also doing probing.