Skip to content

event processing stops if a virtual sink is already loaded, configured and it's the default sink when wireplumber starts

Steps to reproduce:

  1. configure filter-chain by pasting the snippet from https://gitlab.freedesktop.org/-/snippets/7746 into ~/.config/pipewire/filter-chain.conf.d/
  2. start a session normally
  3. make this filter-chain the default sink
  4. stop wireplumber without stopping pipewire or the filter-chain
  5. start some audio playback stream while wireplumber is still stopped; in my case, I am doing that by inputting weird keystrokes on the tilix terminal, which causes gnome-shell to create a stream to play the "alarm bell" sound
  6. start wireplumber
  7. start qpwgraph and notice how only the filter-chain is shown, even though wpctl shows all nodes; also, no audio works at all

What is going on:

The problem seems to be that wireplumber attempts to link the stream to the filter-chain very early in the startup process. Because the filter-chain is an "Audio/Sink", it is considered to be a "device" in si-audio-adapter, so the code tries to configure its PortConfig to "dsp" mode. However, the PortConfig is already configured and all the ports exist. The si-audio-adapter typically waits until the ports have changed in order to consider a PortConfig configuration done... And that is practically a deadlock. The filter-chain never changes anything in its ports configuration and si-audio-adapter waits for ever.

Note: this probably also affects 0.4, but it's very noticable on 0.5 because if the si-audio-adapter does not activate properly, then the si-standard-link also does not activate and the "linking/link-target" hook never finishes, blocking all other event processing for ever.

I tried to mitigate that by looking at the existing PortConfig to see if it matches the one we are about to set and if so, skip the configuration, but it doesn't work for some reason and even if it did, I think it's tricky to get it right for all sorts of different cases (considering passthrough, convert, format changes, etc...)

Perhaps an alternative approach would be to just wait for Props changed (this is always emitted when the adapter PortConfig is set, see https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/plugins/audioconvert/audioadapter.c#L666 ) to confirm potential changes in the format and then only wait for new ports if the "mode" was changed.

Edited by George Kiagiadakis