26 Jan
2022
26 Jan
'22
6:12 p.m.
On Wed, 26 Jan 2022, Paul Davis wrote:
On Wed, Jan 26, 2022 at 6:42 AM David Runge
<dave(a)sleepmap.de> wrote:
On 2022-01-25 16:02:29 (-0700), Paul Davis wrote:
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
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).