[Jack-Devel] stepping down

Spencer Russell sfr at media.mit.edu
Sun Jan 31 05:12:02 CET 2016

Thanks Paul, for all your work on JACK and Ardour. You’ve been, and continue to be, a huge force in open-source audio. I remember back in 2004 when I was a college student interning in Ron Parker’s recording studio, talking on IRC, reporting bugs, and testing out new builds. It was a formative time for me. I’m amazed and grateful that you’re keeping Ardour moving, relevant, and useful.

I agree JACK probably isn’t the right solution for your basic DAW user. That said, I think there’s great value in the general paradigm of separating the routing from the applications. As an application developer, it’s great to just expose your ports and make routing Somebody Else’s Problem.

I definitely don’t think JACK is dead (and that’s not how I read Paul’s words). Sure, there aren’t a bunch of new features all the time, but that’s not why I use JACK. It’s plumbing that works well. It enables things that are hard to do otherwise. Long Live JACK(N).


> On Jan 30, 2016, at 1:04 PM, Paul Davis <paul at linuxaudiosystems.com> wrote:
> On Sat, Jan 30, 2016 at 11:50 AM, Benjamin Schmaus <benjamin.schmaus at gmail.com <mailto:benjamin.schmaus at gmail.com>> wrote:
> + jack-devel
> pls see question for Paul below.
> On Sat, Jan 30, 2016 at 8:48 AM Benjamin Schmaus <benjamin.schmaus at gmail.com <mailto:benjamin.schmaus at gmail.com>> wrote:
>  as the years have gone on, although I am still delighted by the technical quality and 
>    the conception of JACK, I no longer think that it is a particularly good idea for most users. There
>    are times when it is useful
> Could you elaborate on this?  Curious to know more.
> JACK was developed in part because of the absence of a viable plugin API on Linux. It allowed people to "glue together" whole applications rather than load plugins into a host. This is pretty cool, no question. But the session management aspects of it are not that cool, and despite both the JACK session API and the Non session manager and other things that falktx (Filipe) have done, the situation for users really hasn't ever gotten to the point where reloading a "JACK session" comprised of many individual applications is as easy as it ought to be.
> By contrast, we now have a fairly excellent plugin API (LV2) that is supported by several hosts, a number of which offer up quite different models of plugin loading, control, management and usage (Contrast, for example, Ardour, Carla, Qtractor, Non-foo and jalv). I think that most users are better served by developers creating LV2 plugins and the users loading them into one or more hosts of their choice (the so-called "monolithic environment" approach). This allows save+reload to be simple, fast, and reliable.
> There will continue to be times when using JACK to glue together applications is still a really useful thing, and I hope that JACK will continue to be there to support those times. But I don't think JACK is generally the right solution for most users, most of the time. The one big positive it still offers: multiple applications can access the audio device at the same time, with low latency and synchronous behaviour. This is an important feature not offered by ALSA or PulseAudio, and for that reason alone, JACK remains important. It also the case that JACK is the only cross-platform system for doing inter-application audio.
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel at lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160130/8cedad8a/attachment.html>

More information about the Jackaudio mailing list