On Mon, 29 Dec 2025 01:09:07 +0100 Michael Jarosch &lt;riotsound(a)riotmusic.de&gt; wrote: < Snip> They are both directly altering the audio backend volume, not some local volume control. -- Will J Godfrey {apparently no longer an 'elderly', now a 'senior'. Is that promotion?}

On Mon, Dec 29, 2025 at 01:09:07AM +0100, Michael Jarosch wrote: This is just more example of something that IMHO just should be *impossible by design* on an audio system used for anything but 'consumer entertainment'. This applies in particular when you main system is driving a PA system, a broadcast transmitter, streaming service, studio monitoring or an artistic 'audio installation' in a public space. The rules to enforce this a very simple: 1. No audio application should ever connect itself to a sound card or another app unless it is explicitly configured to do so. 2. No audio application should have direct control of the sound card(s). Any hardware gains etc. are either fixed (preferable) or set by a dedicated application. If an app offers a volume control, that should work by setting its own output signal gain internally. 3. Same for buffer size, sample rate and format, etc. 4. 'System' configuration is fixed unless it is explictly changed. In particular just *installing* a new application or new audio hardware should never modify it. 5. 'Session' configuration (which apps connect where and how they behave) is either manual or controlled by a session manager that is completely separate from any 'system' level setup. This includes any 'automatic' functionality such as dimming music when a phone app receives a call - you don't want that all the time. I have held this opinion since (around 20 years ago) a desktop app - (CD burner) played some full scale amplitude square waves on completion of its task. You can probably imagine the result when your monitoring is set to produce 83 dB SPL for a signal with an RMS level of -20 dBFS (a typical studio setup) [1]. The repairs turned out to be quite expensive. So far for me using Jack for anything serious and either a separate sound card or the ALSA->Jack plugin for everything else has worked quite well - it keeps the two worlds (almost) perfectly isolated from each other. Now I wonder how to achieve this with Pipewire. All of it seems designed to do the exact opposite. The only way to do this would be to have Pipewire as a Jack client, or have it configured such that it *never* tries to access the hardware used by Jack. Note that having Pipewire to 'release' that hardware on demand is *not* a robust solution - it still allows Pipewire to access that card when Jack (for whatever reason) is not running. Looking at the Pipewire configuration guide [2], this just seems impossible. I stopped counting the number of config files (at least 10) for all its components, and to make matters worse, each of these has a correspondig 'drop-in directory'. The defaults are go in the wrong direction. Whatever is set up using these will be *extremely fragile*, just installing a new app could completely mess things up. I'd love to be proven wrong, but so far everything I've read on this list and elsewhere just confirms my impression. [1] https://www.sonorissoftware.com/the-k-system/ [2] https://docs.pipewire.org/page_config.html -- FA