On Sat, 2010-04-17 at 12:10 +0200, Stéphane LETZ wrote: > 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.
It's pretty odd that you guys didn't discuss this clearly with each other. It seems that people have an opinion about something, but only share this with people who have the same opinion and not with the one who himself or his code is subject of 'critique'. This is bad communication and bad team management. > 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. It would be good if an '(mini) JACK Conference' will be organized, where JACK developers can speak each other face to face, code to code. And share future vision, coding vision etc. IRC and mailinglists are great, but not always the good method for communication. Regards, \r _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
