Get/set volume based on `media.role`, without doing so through existing nodes
I haven't been able to find an ideal way to control persistent volumes of applications with streams restored through their media.role
property. Apologies for the write-up if I missed it :).
As I understand, streams, with a key such as Output/Audio:media.role:Music
in restore-stream
, are saved whenever any node, with some media.role
property value, has its parameters change. Meaning, the only way to persist the volume for a media.role
value in WirePlumber is to change a currently existing node's parameters. However, this is less than ideal as outlined by PulseAudio documentation's section on developing UI for saved volumes:
Some types of sounds are very short in nature and hence might appear only for a very short time as a proper stream. That makes it difficult to control them in the volume control UI — before you can grab the slider the slider might already be gone again. Those short sounds are usually event sounds. It hence might make sense to add an explicit slider for event sounds that stays available all the time.
Note that the issue exists for both GUI controls and CLI ones, like wpctl
.
Here are some methods through which I think media.role
-specific volumes could be controlled:
- Use a homemade script to read/write
$HOME/.local/state/wireplumber/restore-stream
- Implement
media.role
IDs intowpctl
'sparse_id
so that the(get|set)-volume
commands work -- However, it seems to be more complicated than that sincewpctl
has no visible/direct relation withrestore-stream
and works only on existing nodes. - Spawn a node with some
media.role
value for a short duration and update its volume (thus triggering therestore-stream
script'ssaveStream
)
To me, it seems options 1 and 3 may work as temporary hacks for the end user, but something like option 2 would be ideal in the long term. But since wpctl
's nature doesn't seem compatible with the idea of interacting with IDs that do not resolve to currently existing objects, I'm not sure how problematic such an implementation would be. I'm too unfamiliar to judge whether it is viable, but option 3 seems like its key idea could be a decent bridge between wpctl
and restore-stream
too, as another official solution.
Any suggestions/plans to deal with this?