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
rn...@rncbc.org
_______________________________________________
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
