[LAD] Re: Status of Pipewire

Hi Fons,

On 08/02/2023 12: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.

I'm really glad you raise the questions...

I feel in the same situation (more as a user) and still find Pipewire 
quite confusing.

I recently reinstalled my uses Manjaro (Arch-based) and I see I _do_ 
have a 'pipewire' package installed, but it looks like I'm actually 
running pulseaudio (?) and am able to run jack and use my 
jack-pulseaudio sink _if_ needed - as I have usually done since years.

That's confusing enough, my intuition is that pipewire (at least on Arch 
and Arch-based distros) is some sort of 'metapackage' (the upstream 
points to pipewire.org) and then the actual functionality is in the 
myriad of pipewire-* packages such as pipewire-audio, pipewire-alsa, 
pipewire-jack.

Then I see that pipewire-jack conflicts with both jack and jack2 which 
makes me very very reluctant to install them as a replacement (I use 
jack2): on my older machine I gave it a go and Ardour wouldn't even start.

I don't want to sound over-critical, just as you (and maybe other users) 
I'm simply pretty confused. The documentation, at least for me, also 
seems a bit confusing when it comes to JACK [1].

It might just be a matter of time, meaning Pipewire is still a 
relatively new project and quite ambitious I'd say. I'd also imagine 
that (understandable) it's mostly focusing on desktop audio (/video) and 
not on pro audio.

> 
> 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. 

I agree. For me pulseaudio is 'everyday' non-pro-audio, jack for 
pro-audio and then if needed use a sink. Quick and easy and good to have 
two distinct approaches. If I'm recording or making audio I'm 
(typically) not watching youtube videos et. al.

So, I'm also really interested in the questions you pose (and possible 
answers).

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 ?

I think the final aim of Pipewire is to _replace_ JACK. It's not clear 
for me if the option to run JACK 'natively on demand' is considered a 
kind of transitionary phase or will remain. If the latter maybe one 
could consider (and use) Pipewiere eventually as Pulseaudio is used today?

> 
> 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.

As said, this (at least logically), sounds really similar to the 
pulsaudio-jack sink concept... For instance what I now have in a script 
is something along the lines of:

pactl load-module module-jack-sink
pactl load-module module-jack-source

and get pulseaudio as an in/out jack client.

> 
> 
> [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,
> 

Lorenzo

[1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK
_______________________________________________
Linux-audio-dev mailing list -- linux-audio-dev-cunTk1MwBs/[email protected]
To unsubscribe send an email to linux-audio-dev-leave-cunTk1MwBs/[email protected]