[LAU] Re: pipewire, wtf, part 2

On Mon, Dec 29, 2025 at 01:09:07AM +0100, Michael Jarosch wrote:

> The two apps cause an interaction I just didn't expect

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



_______________________________________________
Linux-audio-user mailing list -- linux-audio-user-cunTk1MwBs/[email protected]
To unsubscribe send an email to linux-audio-user-leave-cunTk1MwBs/[email protected]