[LAU] Re: pipewire, wtf, part 2

I guess I have to point out something…

I'm not against pipewire. The main reason why I thought I should report 
this on this list is that I wanna find out more about it before creating 
a bugreport…

Therefore I'm asking (for both of my issues):

Does other people experience the same?
Is this a kind of misconfiguration (on linux-distribution level)?
Is this really pipewire's/wireplumber's fault?
Is this a bug?

It's not about complaining, it's about making things better. I found 2 
issues which I think are not the way pro-audio-people want them to work. 
So, if we don't raise our voice, it's no wonder our wishes are not being 
heard…

Please, help! :)

Greets!
Mitsch


Am 29.12.25 um 14:22 schrieb Fons Adriaensen:
> 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
>
_______________________________________________
Linux-audio-user mailing list -- [email protected]
To unsubscribe send an email to [email protected]