[LAD] Re: Status of Pipewire

On 2/8/23 11:09, Fons Adriaensen wrote:
> 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.
> 

TL;DR (IMHO) pipewire is a dang good replacement to pulseaudio (and 
possibly jack) for *consumer*/*desktop* scenarios; though, not so good 
for the pro-audio scene, as far as "deterministic" and "stable" 
low-latency goes, at least as far as good ol'jack.

a proverbial YMMV ensues...

the biggest problem I've come around is that most distros package 
managers will command you to ditch genuine jack altogether, whenever you 
try to install pipewire-jack (ie. the so called "jack replacement" 
libraries); this is simply outrageous for us (me included) good old jack 
folks; however I've been dwelling with this on my own premises, whenever 
a new pipewire version comes along (openSUSE Tumbleweed here).

again, YMMV

just my 2c.
-- 
rncbc aka. Rui Nuno Capela
rncbc-d0bMj/[email protected]
_______________________________________________
Linux-audio-dev mailing list -- linux-audio-dev-cunTk1MwBs/[email protected]
To unsubscribe send an email to linux-audio-dev-leave-cunTk1MwBs/[email protected]