"Holistic" volume controls: seeking opinions

[Ralphred]

So, "we" get "our" media from various sources nowadays, some of the authors understand the concept of "volume normalisation", others erroneously spell normalisation with a "z", and so on...
Suffice to say that the "old way" of having one or two sources actively playing through a "master" volume control does not intuitively match the way in which we source/consume media anymore.
As an example of a "background set-up" I have the physical knob of my 5.1 speakers set to ~80-90%, I have alsamixer set to 100% on any hardware that matters, and the "pulse/pipewire master" (PPM) set to 35% on login. I control the PPM with media keys (+/- 1%) and other KB shortcuts (+/- 5/20% respectively).

I've come to the conclusion (over time) that this is "sub-optimal", and having PPM set to 100%, and any "new audio source" set to 35% by default would yield the same result, but with greater "intuitive convenience for change".
Hence my (prospective) new baby, holistic volume control (HVC) - It expects everything to be set at sensible (no one wants you too amplify the sound of your mobile phone switching cell towers etc) maximums, then all new sources of audio are pegged at your chosen default level (e.g 35%).
The next aspect is "active window correlated volume control", (somehow) there is a local database that correlates the equivalent of xdotool getactivewindow with a specific "audio-server client-instance", so when you mouseover an ffplay window and hit the "voldown" media key, it doesn't decrease the PPM volume, but the specific "audio-server client" volume associated with that instance of ffplay on the "audio server". Similarly you open the latest publication from you favourite podcast host and they are (because reasons) in their car and the audio couldn't wake a sleeping cat, you hit volup and instead of you hearing the wind blowing past your character in the minimised tab of your game, it just turns up your "podcast host's" volume.

I understand that an endeavour of like this requires "complicity" on multiple levels (excepting a lot of trial end error/coded automagic self config nonsense), hence me testing the waters for others who might say "Yeah that's a good idea, I'd like that." as opposed to "FFS; just turn the volume knob up or down you morbidly autistic geek!"...

[szatox]

I solved this problem with an aggressive compressor (easyeffects + lsp-plugins, at least for now).
It does get stuck every now and then at the end of audio stream though, which requires restarting ee. Still, makes the overall experience much better. Once I get back to digging through wireplumber's docs, I might try replacing it with Calf. (Ee apparently _should_ work with calf, but it clearly doesn't on my system. Oh, well... Maybe I'll fix this too, eventually)

There is "automatic gain control" plugin too, but it's much slower, so you can get your ears blown by a sudden volume change. Compressor does a better job.
_________________
Make Computing Fun Again

[Ralphred]

Yeah, I've toyed with compressors too, they are good for traditional broadcast media but are also really resource hungry.

[szatox]

Hmm... So, you played with compressors, decided they eat too much, and ditched them in favor of Rube Goldberg machine.
You know, maybe AGC would actually be a good option for you. I bet it would be far less resource hungry, just follow it up with a limiter for overdrive protection. It must be possible to spawn additional instances of AGC to adjust multiple independent audio sources, though I don't know of any software that already offers is. Still, wireplumber is scriptable, so maybe it could be used to manage that too, in addition to connecting virtual ports with virtual wires.

Unless you just really really really like Rube Goldberg machines, in this case there's no helping it
Or am I missing some important point? Because I don't see how using multiple controls for various applications would be more convenient. I mean, it's good too _have_ them, but I don't want to _be_using_ them. I'd rather have source volume normalization + a single output knob for matching the playback device to my ears.
_________________
Make Computing Fun Again

[Ralphred]

[szatox]

I see.
I this case I think you're looking for a "priority stream" or whatever it's called, and I think pipewire borrowed this concept from pulseaudio.
While a priority stream is connected, the sound server automagically suppresses all other streams with a predefined, used-configurable factor (0.3 by default) to make sure the priority stream won't be drowned in the noise.

Edit: pw uses terms: media roles and duck(ing), those might be a good starting point.
_________________
Make Computing Fun Again

[Ralphred]

So, I've got a PoC working and it's surprisingly low cost.
It's kinda 'hacky', using a blocking subprocess.Popen(tail -F).readline() to sit and wait for relevant information to appear in pulseaudio.log (log-level=info). When a new client is added it maps the "client source index" to it's PID in an index file, and removes it from the index file when the client connection is ended. This is where the "default volume" of new clients is set to 50% << I tried to make it miss and produce a "too loud" client but couldn't to it. I've got no way of differentiating between different browser tabs, but have only tested my daily driver chromium based browser (all client connections report coming from the child pid of the "playing" tabs subrocess, but I've got no way of gleaning that pid from the browser for now).
I should probably investigate what sort of information is published on dbus to do away with the logfile entirely at some point, but the ability to read the entire log before starting to tail lets me build indexes of existing connections on start-up...

I remapped the volume up and down keys to simple script that identifies the pid of the window under the mouse, checks if it has an entry in the index file, alters that client ID volume if it does, and defaults to the "normal behaviour" if altering the current default sink volume is it doesn't.

I tried using module-stream-restore but it's about as reliable as a 1988 Fiesta bought from "Honest Jon's Used Motors"; my expectation is that if a similar pipewire module exists it probably works. This does leave me in the situation that I can easily create my own "application name >> default volume" mapping file though just by populating it before a client connection closes.