[LAD] Re: Status of Pipewire

Hello all, I've been contemplating trying out Pipewire as a replacement for Jack. What is holding me back is a what seems to be a serious lack of information. I'm not prepared to spend a lot of time and risk breaking a perfectly working system just to find out that it was a bad idea from the start. So I have a lot of questions which maybe some of you reading this can answer. Thanks in advance for all useful information. A first thing to consider is that I actually *like* the separation of the 'desktop' and 'pro audio' worlds that using Jack provides. I don't want the former to interfere (or just be able to do so) with the latter. Even so, it may be useful in some cases to route e.g. browser audio or a video conference to the Jack world. So the ideal solution for me would be the have Pipewire as a Jack client. So first question: Q1. Is that still possible ? If not, why not ? If the answer is no, then all of the following become relevant. Q2. Does Pipewire as a Jack replacement work, in a reliable way [1], in real-life conditions, with tens of clients, each maybe having up to a hundred ports ? Q3. What overhead (memory, CPU) is incurred for such large systems, compared to plain old Jack ? A key feature of Jack is that all clients share a common idea of what a 'period' is, including its timing. In particular the information provided by jack_get_cycle_times(), which is basically the state of the DLL and identical for all clients in any particular period. Now if Pipewire allows (non-Jack) clients with arbitrary periods (and even sample rates) Q4. Where is the DLL and what does it lock to when Pipewire is emulating Jack ? Q5. Do all Jack clients see the same (and correct) info regarding the state of the DLL in all cases ? The only way I can see this being OK would be that the Jack emulation is not just a collection of Pipewire clients which happen to have compatible parameters, but actually a dedicated subsystem that operates almost independently of what the rest of Pipewire is up to. Which in turn means that having Pipewire as a Jack client would be the simpler (and hence preferred) solution. [1] which means I won't fall flat on my face in front of a customer or a concert audience because of some software hickup.