[LAD] 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.

Ciao,

-- 
FA




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