On Wed, 26 Jan 2022 at 15:30, Paul Davis <paul(a)linuxaudiosystems.com> 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:
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.
Running PipeWire on top of JACK was something that was requested early
on because firewire audio support was broken in the
kernel and there was no other way to run that hardware otherwise. Now
that this is largely fixed, running PipeWire on JACK is
pretty pointless, confusing and no longer supported. I think I'm going
to remove it in some future version...
Wim
I hope they change this in the future once the
Pipewire JACK implementation is suitable (or maybe even before).
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user