Subject: The Situation(s) With JACK
Date: Thursday 8th December 2011 13:04:57 UTC (over 4 years ago)
It has come time to address the situation with JACK. This widely-used and innovative project has stalled out and is causing as many headaches for users (potential and actual) as it is helping. Lets take an honest and harsh look at the problems: 1. there are at least 3 different implementations of JACK. This is not a problem in and of itself, but in the real world, it contributes the remaining problems in real ways. 2. there is no defined API version that clients can be said to depend on (that is, libjack from different implementations of JACK do not come with a standard soname that can be used in dependency determination). In addition, JACK's attempted use of weak linkage to deal with an evolving API turns out to be based on a serious misconception on Linux (it does work on OS X, and sometimes on Linux too). 3. there is widespread confusion about the relationship between Jack1 and Jack2, with an overwhelming number of people believing that Jack2 is the newer, better version of Jack1. 4. JACK was one of the first audio APIs to provide network streaming, but the existence of two incompatible implementations of netjack makes network streaming more to difficult to explain than it is to actually do. Both implementations have their benefits, but there is absolutely no talk of any unification and some notable resistance to it. When the typical question arises "Can I use JACK to stream audio from A to B?" the answer is so complex that many people just give up (and probably rightly so). Contrast this to, for example, using the AUNetSend and AUNetReceive plugins on OS X. It just makes a mockery of netjack in terms of ease of use (though latency is terrible). 5. after seven or eight years, the API still has not reach version 1.0.0 6. largely as a result of (2), distributions and applications are starting to create a situation where despite the fact that Jack1 and Jack2 are, in fact API and ABI compatible, explicit requirements for Jack1 or Jack2 are in effect. They are wrong to do so, but their reasons for doing so are entirely understandable. 7. any new extensions to the JACK API (such as an upcoming metadata proposal from David Robillard and myself) require duplicated effort across different implementations, which is silly and not very productive. 8. Dangling features such as interactions with multiple devices have totally different implementations in Jack1 and Jack2, with notable drawbacks in each case. Where Tschak solves them, it does so having effectively dying as an unreleased private project. 9. Despite the presence of JACK Session support in a number of notable applications, many developers apparently feel that it is unfinished or incomplete or in some other way not worth using "at present" 10. The existence of LADISH continues to produce confusion for users wondering how best to do some of the things that LADISH does, because there are now other ways of doing them. 11. Interaction with PulseAudio continues to be a nightmarish headache for a large number of new JACK users. 12. By adopting jackdbus, distributions have sanctioned a way of using of D-Bus that was explicitly disavowed at LAC Berlin. This also isn't a problem in and of itself, but it has created a situation where (almost) all interaction between JACK and everything else that is accessible via D-Bus is the responsibility of Nedko, with whom I now have a severely antagonistic relationship and several other people have a ... difficult ... relationship. I take as much blame for the relationship part as anyone else, but it remains the case that JACK interacting with other parts of Linux via D-Bus is a good idea that is currently limited by the entire constellation of issues surrounding jackdbus. Torben has already demonstrated an alternative implementation (jack.py) that follows the guidelines set up at LAC Berlin, but it remains a small, experimental project barely used by anyone. 13. The only people to do work on JACK development over the last couple of years confine themselves to specific versions of JACK, and despite nominally friendly communication, do not really collaborate with the others. (Note that I am including myself in this). In summary, although Jack1 and Jack2 continue to provide useful functionality to users and the overall design of the API continues to have many fans and a relative elegance, the *project* as a whole is in a serious condition. I blame myself for some important parts of this situation. When Stephane originally wrote jackdmp as an experiment with multi-core/parallel support and other important ideas, it was decided by the JACK group meeting at LAC Berlin that jackdmp would become the successor to jack1. Instead what happened was that Jack1 and Jack2 have continued to evolve in parallel, largely because the primary maintainers/developers of Jack1 (Torben and myself), while respectful of the ideas that Stephane designed in jackmp, find the actual implementation to be something we don't wish to work with. At no time have I, as the supposedly benign dictator of the project, put my foot down and said "this has to stop", because it seems wildly inappropriate. Stephane (and others) are totally free to continue their work, and distros are totally free to pick whichever implementation they wish. Nedko has continue to work on Jackdbus and LADISH, and has seen his work widely adopted by many distributions. Torben has been free to do a completely new implementation ("tschak") which merges jack1 and jack2 features/design. I can't stop that, and I'm not sure I want to - these efforts have been incredibly valuable as research projects and providing useful functionality. But ... this freedom has come at quite a high cost for the user (particularly the potential user) community, as detailed above. For developers, its not so bad - the different implementations are, in fact, API and ABI compatible, and the issues with netjack are invisible to clients. The dithering around with LASH/LADISH/JackSession and the core design issues that they represent should have been solved years ago and weren't, which does impact developers a bit, but for most its a "use it/don't use it" choice that doesn't really affect them, only those users who want to use one of LADISH/JackSession for some purpose. A few weeks ago, I had an extremely negative IRC interaction with the maintainer of the JACK plugin for audacious. Some of what this person said was based on ignorance and incomplete understanding, but at the root of his complaints and observations were a few perfectly valid criticisms of JACK as a project (rather than as a technology) And so now .... It Has To Stop. I do have a proposal for how this is going to stop, but before I put it forward, I would like to first see if there are any other ideas floating around on the mailing list that have not come up when I've discussed this situation on IRC. Once any discussion about this email settles down, I'll outline my proposal (whatever it ends up being at that point). This is a decision that affects users, packagers, distributions, developers and other people. Despite a radically innovative (and, thanks to Stephane, cross-platform) design and unmatched functionality, the project needs a change in direction in order to live up to its potential. If it can live up to it, then JACK will be the simple, natural, functional choice for audio and MIDI on all 3 major OS platforms including network streaming, and the confusion and stagnated development that it embodies now will be a thing of the past. If it can't, JACK will continue to be a useful tool, but will likely slowly rot. Lets try to avoid that if we can.