Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Could it change the strategy based on whether the networking support is loaded or not?

Yeah, I know. But that's not a good-enough excuse for 50% load. That 5% is caused by one or two application sources going to one hardware sink. Everything else is dormant. Thus PA's pavucontrol would only have to enable my three hardware sources, preferably with suitably lowered bitrate. Thus, 15% at most. Everything above that is bad design (and would kill audio on a system that does actual multi-channel processing).

There's a number of things you can do. Like blocking the connection of a new sink if it introduces a delay of more than .1 second or whatever, or keeping it out of the loop.

For instance, a phone call on Bluetooth with that kind of delay is annoying but survivable, while he same thing on speaker is not. Also, a phone call shouldn't suddenly goes from .05 to .5 seconds latency because Pop's hearing aid also wants to listen in.

Decisions like these (do you *want* Pop to listen? should his microphone be cross-connected? or should the call switch to him entirely?) should be under the purvey of a policy manager, not any single application. PA doesn't have that.

If the audio system is also the video system it can delay the video to match.

> The pavucontrol UI is deprecated

Could you please elaborate what should be used instead?

https://www.freedesktop.org/wiki/Software/PulseAudio/About/ doesn't list pavucontrol as deprecated; i.e., it's not in the section "obsolete or out-of-date UI tools".

> Please, let's stop the hand-waving and anecdotes and concentrate on what PipeWire actually >TECHNICALLY does (or even theoretically could do) that's so much better.
>
>My issue is that TFA and other official PipeWire sources make sweeping claims suggesting that >PulseAudio is high-latency, resource-intensive etc and then do nothing to back those claims up, >nor explain how they improve over it. And this comment thread is just another example of that.

I have posted some Performance measurements between PipeWire, PulseAudio and JACK2 on the Wiki now: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/...

>pavucontrol is not compatible with PipeWire so it's not like PipeWire can improve over that anyway.

You can run pavucontrol under pipewire just fine and I often do to check signals and change volumes etc.

Pipewire runs the peaks resamplers in the pavucontrol process. The effect is that the load is shifted from the server to the client. I don't have numbers to compare but I remember pavucontrol uses approximately the same CPU while the Daemon much much less in the case of pipewire.