On Wed, 26 Jan 2022 at 15:30, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, Jan 26, 2022 at 6:42 AM David Runge <dave@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx > https://lists.linuxaudio.org/listinfo/linux-audio-user _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
