EasyEffects fights with SteamVR for audio re-routing

[misyltoad]

EasyEffects Version

8.2.8

What package are you using?

Arch (easyeffects)

Distribution

Arch Linux

Describe the bug

SteamVR with Steam Link (VR Game Streaming) attempts to redirect all VR apps audio output and input to our audio node for the HMD.

EasyEffects will fight with us on that, and it removes our wires and redirects stuff to the Easy Effects Sink.

I wrote the code in SteamVR to do the audio rerouting, so hopefully we can figure something out so EasyEffects + SteamVR both play together nicely.

Some things of note of the current state of things that might be useful for any logic here:

• SteamVR links and sources are marked with "steamvr.internal": true
• The sink and source for vrlink are called vrlink-source and vrlink-sink.
• The media type/category/roles are "Audio/Capture/Communication" and "Audio/Playback/Game"
• media.software is "Steam Link"
• The streams are named "vrlink_microphone" and "vrlink_output" respectively.

Maybe we want something more generic though than hardcoding for Steam Link here. If we can decide on something (or there is an already existing standard I don't know about), then I am happy to implement it on the SteamVR side.

Thanks!

Expected Behavior

No response

Debug Log

Debug Log

Paste your log here

Additional Information

No response

[wwmm]

Two applications trying to redirect streams will always conflict if something is not done so that one gives up the move. We had a similar situation with pipeweaver #5185. We could find a combination of configuration on both sides that helped there. It should be possible to achieve the same here.

SteamVR links and sources are marked with "steamvr.internal": true
The sink and source for vrlink are called vrlink-source and vrlink-sink.
media.software is "Steam Link"

Hum... This seems too specific to steamvr to be used on our side.

The media type/category/roles are "Audio/Capture/Communication" and "Audio/Playback/Game"

We could block based on media role or category. But it seems too generic and might block other things without we knowing about it.

The streams are named "vrlink_microphone" and "vrlink_output" respectively.

What happens if you add SteamVR streams to easyeffects user blocklist? This is where we process this list

easyeffects/src/pw_node_manager.cpp

Line 234 in d13215c

const auto user_blocklist = (media_class == tags::pipewire::media_class::output_stream) ? DbStreamOutputs::blocklist()

We take into account node name, application id and the process binary name.

In any case this would avoid easyeffects moving StreamVR streams around. Not other apps it could be managing. For those the workaround found in the pipeweaver discussion I linked above would probably be necessary.

[wwmm]

By adding to our blocklist I meant here