26 Jan
2022
26 Jan
'22
8:08 p.m.
On 1/26/22 6:29 AM, Paul Davis wrote:
On Wed, Jan 26, 2022 at 6:42 AM David Runge <dave(a)sleepmap.de
<mailto:dave@sleepmap.de>> wrote:
On 2022-01-25 16:02:29 (-0700), Paul Davis wrote:
I think it shows consideration for the actual users of the system[*],
and for a transition to a new implementation of jackd without
necessarily breaking existing workflows for users of jackd.
Again, PipeWire *is* JACK and it is also
PulseAudio. It it not a
replacement for PulseAudio, it is a replacement for both of them.
Once
you are using PipeWire, everything you've
read about JACK bridging
etc. becomes incorrect and irrelevant.
That is technically not necessarily true, as it depends on how the build
of pipewire is configured
I was wrong, for sure.
But as a policy question, I think this is probably a serious mistake by
the pipewire team (probably mostly just Wim). It has been bad enough
having 2 independent, different implementations of the JACK API. Now
Pipewire adds a 3rd (not great, but also not so bad), but then in
addition says "oh, you don't *have* to use this implementation, the
others are still available". In terms of the famed "user flexibility"
this is, uhm, cool I suppose. But in terms of Pipewire's broader goals,
it just adds to (and continues) the mess.
I find it great that it is possible to test pipewire (the pulseaudio
replacement stuff and the jack stuff independently), report problems,
and go back to plain old jackd if your audio workflow is somewhat
compromised or unstable.
That is what I do on Fedora - it is possible to install either the
pipewire implementation of jackd, or the "normal" jackd (jack2,
actually, which I still use in my regular audio work)
I hope they change this in the future once the
Pipewire JACK
implementation is suitable (or maybe even before).
Nope, not before please...
Best,
-- Fernando
[*] old timers might remember the transition to pulseaudio, which was
not, let's say, graceful...