Re: [LAD] [Jack-Devel] distros migrating to JACK2?

At Grame, we started working on JACK (jack1 at that time) in 2003 and our first commitment was to port the C code base on OSX. Even if the result was working, we rapidly felt that the C code base was not flexible enough to evolve in the direction we wanted to explore: multi-platforms support, SMP and glitch-free connections (among other ideas we had...) . Around 2004-2005 we had a new C++ based code base that was first developed on OSX, later ported in Linux (2005), on Windows (summer 2006) and Solaris (summer 2008 as a result of funding coming from RTL french radio). In 2004 we also found the way to better "integrate" JACK in the CoreAudio architecture on OSX (the JackRouter JACK/CoreAudio bridge) that allowed any CoreAudio application to become a JACK client, thus participating in the success we had on OSX with the JackOSX package. I think the "about 3 years ago, the JACK mini-summit in Berlin" Paul told about, was actually during LAC 2008 in Kohn. It was my impression that most of the JACK community was interested to see jackdmp (renamed jack2 at that moment) become the future of JACK, and late 2008 and 2009 was an intense period of work to reach this goal. Nedko (mostly but some other) did a huge job of improving the build system, implement the so-called "JACK Control API" (or at least the server side of it) and helped in other areas. The D-Bus based server control code (Nedko) was also integrated at that time. In spring 2009 started this "D-Bus war" and after endless discussion with people with strong opinions (Fons, Nedko...) it appeared that no agreement could be found. The best that we could achieve (in my view) was to clearly define the "JACK Control API" as the "frontier" between the external world that wants to control the JACK server, and the server code itself, and report all more sophisticated control mechanism outside. At about the same time, some developers (Torben, Paul ...) started to rebirth the jack1 codebase, and it appeared more and more clear that the "jack2 become the official code base" idea start to become a vanishing goal. I must say that I still don't have a clear understanding of why this happened. I still don't understand the sentence "Like Torben, there are some design decisions there that I have questions about." and I think explaining it in more details would really help.

The fact that jack1 and jack2 are almost indistinguishable in everyday use is quite satisfactory, but at the same time the subtle difference that stay continue to cause some endless comments from users about the "real" advantages of each of the two implementations. I still see reports from "more xruns" here or a "bit less CPU use" there, but with no real data and clear "step by step way to reproduce issues" that would help to fix remaining bugs in jack2 codebase (for example jack2 still probably has issue with multi-cards support compared to jack1, but AFAICS this is in ALSA backend, and I cannot progress on that without the help of people with multi-cards and knowledge in ALSA backend code). Concerning session management added in JACK codebase, I did not followed the discussion in details. I said to Paul in a private mail that I though it was not a good idea (but maybe I am completely wrong...) but I would certainly not oppose to a implementation for jack2. I remember someone volunteered to work on that ?? I have to say that I become quite tired of all that mess, since I don't see any clear way to solve the situation. After about 5 years of real commitment in JACK project, I decided to move back a bit and work on some other stuff. I still try to follow bug reports and jack1 changes, release a package from time to time and maintain JackOSX project. I still think some interesting ideas (like the "pipelining" mode that currently stay in a jack2 branch...) are of interest (especially since we now see with those "4 cores/threads" model in new laptops...) and should be pushed in mainline.