LADI is a long term project to improve desktop integration and user workflow of Linux audio system based on  JACK.

History

By the end of 2007 it became evident that while JACK is a great system it has some drawbacks from the user workflow point of view. jackd was (still is) an executable used to start the JACK server. It is a per-user service as opposed to most UNIX daemons that are system wide. As such people tend to put it in the two more known categories of "application" and "system daemon". However JACK server falls somewhere in between.

The application approach suggests that user manually starts the JACK server. This approach has been largely incorporated in  QJackCtl but still some users, especially the commandline-oriented ones, tend to start JACK server by starting jack manually.

The system daemon approach suggests that JACK server starts when it is first needed (or on boot, or on login) and terminates when it is not needed anymore (or on shutdown, or on logout). QJackCtl ca mimic this approach by binding the JACK server lifetime to QJackCtl lifetime. Some Linux distributions provide init.d scripts. Other incarnation of the "system daemon" approach is the autolaunch functionality (start jack server when first app creates a jack client) and the "temporary" option of JACK server (Exit once all clients have closed their connections).

The QJackCtl was (and still is) by far the most popular approach for managing the JACK server. If started by QJackCtl, JACK server in jackd provided a log messages to its stdout/stderr that are captured by QJackCtl and displayed in a window. However if jackd was started through the autolaunching mechanism, jackd throws log lines to stdout/stderr of the process that started it. If the processes was a GUI app, this usually means that user is blind about what happens with the JACK server, except by watching its status in the QJackCtl window its tray icon.

The only available way for control apps like QJackCtl to interact with the JACK server was through libjack, the same library as the is used by regular apps that process audio and midi. This approach has some serious drawbacks. It causes code complication because the control app is under constraints required for realtime processing. Using libjack for control apps also complicates creation of control apps in high level interpreted languages like Python. Finally, because of a bug in JACK server that existed back then, jackd could decide to kill some process and quite often that happened to be a control app like QJackCtl or  Patchage.

QJackCtl, as a control app that can configure the JACK server was bound to the jack commandline options that were available by the time QJackCtl release was made. This causes requirement to bind QJackCtl and JACK server versions to each other. However they are developed mostly independently and unfortunately it happened several times that distribution-provided versions of the packages are mismatched. For example, when a new JACK driver appeared (like the FFADO driver used for FireWire? devices), QJackCtl had to add new UI elements for it, otherwise, there was not GUI way to use the new options. Another example is the two incarnations of the JACK server, jack1 and jack2 (formerly known as jackdmp). They share some of the commandline options but there are also options specific for jack1 or jack2. Thus, user was able to tweak in the QJackCtl GUI options that at least had no effect and at worst caused jackd start failure because of unknown options.

Back then, two places were commonly used as a store for JACK settings. The ~/.jackdrc file that is used by the libjack autolaunching mechanism and the QJackCtl internal settings storage that could be transformed into ~/.jackdrc content. OTOH ~/.jackdrc was not really a settings file, instead, it is a script that started the JACK server. Some people used it to start QJackCtl that in turn started jackd.

While most of these issues can be handled with more user experience, the jack-killing-the-control-app behaviour has shown that the system can benefit from a new approach. Especially given the fact that the control app that was being killed was supposed to restart the JACK server if it crashed. An advanced session handler should do this. If one component of the system crashes, it should not render the whole system unusable unless it is a core component like the kernel for example. Both JACK server and JACK clients are not components that sit that much in the core. They can be restarted and the whole system can be put back if some technical skill is applied.

As a step toward fixing these limitations, jackdbus was created by Nedko Arnaudov. It is an executable that can be seen as alternative to jackd because it can also start the JACK server. However there are some important differences. A well known,  general purpose IPC mechanism (D-Bus) is used for communication between control apps and the JACK server. This ensures that control apps can be implemented much easier because they can be implemented in few lines of an interpreted language like Python. Also because control apps are no longer regular JACK clients, they are not even known to the JACK server itself and thus are are not subject to restrictions that regular JACK app are subject of, and they can share some high-level functionality like the number of xruns that when cleared in one app gets cleared in other apps as well. As D-Bus provides a mean to start a service when it is first accessed. This functionality was used to make jackdbus feel like a real daemon, a process that runs in background and has log file. D-Bus allows both session bound functionality through the session bus (usually this means per user login) and system-wide functionality for daemons that are used by more than one user. jackdbus operates through the session bus.

Juuso Alasuutari and Marc-Olivier Barre joined Nedko Arnaudov`s efforts in improving the new approach for JACK server use. Juuso helped with jackdbus itself, while Marc created a suite of small Python GUI tools for use with jackdbus. This suite was initially called pyjackctl but was later renamed to  LADI Tools. Later, Krzysztof Foltman stepped in and provided great improvements to ladiconf, a JACK server configuration application from laditools package.

At  LAC 2008, there was a meeting that discussed the future of the jackdbus LADI improvements. It was decided to integrate it in jack2 through a special new Control API. As a result in May 2008, jackdbus was merged into the jack2 mainline and was released in the following 1.90 release of jack2.

Status

jackdbus for jack1 exists but is not accepted upstream for various reasons. It can be downloaded from  here. jack1 jackdbus is less used and thus tested mainly because of decreasing motivation to improve it because of upstream rejections.

jackdbus for jack2 is bundled in jack2 itself and can be enabled with the --dbus option at configure stage.