[LAU] Connect pipewire to running JACK server

Len Ovens len at ovenwerks.net
Wed Jan 26 17:12:39 CET 2022


On Wed, 26 Jan 2022, Paul Davis wrote:

> On Wed, Jan 26, 2022 at 6:42 AM David Runge <dave at sleepmap.de> wrote:
>       On 2022-01-25 16:02:29 (-0700), Paul Davis wrote:
>       > 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 hope they change this in the future once the Pipewire JACK implementation
> is suitable (or maybe even before).

Until pipewire supports the ffado backend, being able to run a "real" JACK 
is an absolute requirement. If pipewire is then to take the place of 
pulse, then some form of pipewire-jack bridge becomes a requirement too 
(for many people). The ALSA firewire modules are not even stable enough 
for desktop use let alone audio production.

While firewire audio interfaces are no longer made, the current crop of 
USB devices meant to replace them, fall short. They may work just fine for 
recording, but for live use the stability is just not there.

Beyond that, replacing a perfectly working device with another just to 
keep up is a problem not a solution. (like all the distros that have 
dropped 32 bit support) Churn is not a good thing.

--
Len Ovens
www.ovenwerks.net


More information about the Linux-audio-user mailing list