GitLab

Here is some criticism of the JACK design by the Non-Daw developer, at the time he released the Non-Daw. It might be worth a read, all though I think Robin Gareus did mention somewhere that the info is not 100% correct and/or that LV2 solves this. I'm not qualified to technically comment on it, but maybe this feedback can help making PipeWire as good as possible.

http://non.tuxfamily.org/mixer/doc/MANUAL.html

1.1.2

...

"JACK provides immense flexibility. But, as in most situations, that flexibility comes with a cost. In JACK the cost is a context switch per client. This applies even for many clients which belong to the same process, as in Non Mixer. Various factors go into determining the price of a context switch on any given system. It's not very expensive, but it does add up. It becomes problematic in sessions involving many clients (think 100s), each of which having a small DSP load (often smaller than the cost of JACK's context context switch). JACK could be smart enough to recognize that some clients belong to the same process and could be executed serially without requiring a context switch, but at the time of writing neither JACK1 nor JACK2's scheduling is that smart.

If you're mixing a normal song (couple of dozen tracks) at low latency, this overhead will probably account for less than 1% of the total DSP load. If you're mixing an entire orchestra at ultra-low latency, then it might account for a quarter or more of the total DSP load.

Groups mitigate this cost by reducing the number of JACK clients required for a mix. Strips in a group will execute serially without context switches or thread synchronization--reducing the total JACK overhead. However, if you have several groups, then they may all by run in parallel by JACK2. "

...

" 1.4.1. JACK I/O

Each mixer strip is presented as a separate JACK "client". This helps to avoid the necessity of internally duplicating JACK's routing logic and, with JACK2, permits the possibility of parallel execution of mixer strip signal chains.

The JACK client name of each strip will correspond to the name of the strip.

NOTE: The JACK API makes implementing this far more difficult and kludgey than it should have to be. Please petition your local JACK developer to accept jack_client_set_name() into the API. "

...