jackdmp is a C++ version of the Jack low-latency audio server for uniprocessor and multiprocessor machines.
It is a new implementation of the jack server core features that aims in removing some limitations of the current design.
The activation system has been changed for a data flow model and lock-free programming techniques for graph access have been used
to have a more dynamic and robust system.
Belorussian translation here : http://webhostinggeeks.com/science/jackdmp-be
Future JACK2 will be based on jackdmp codebase. Jack 1.9.8 is the "renaming" of jackdmp and the result of a lot of developments started after LAC 2008.
It is now distributed as a source package including documentation:
jack-1.9.8.tgz contains the source code only (mainly for Linux or Solaris users).
OSX users can get an installer at JackOSX site.
Windows users can get a 32 bits installer here (to be used on 32 bits systems) : Windows 32 bits version.
Windows users can get a 64/32 bits installer here (to be used on 64 bits systems) : Windows 64/32 bits version.
Look at the following using JACK on Windows page for more infos.
Beta of Windows 1.9.9 version, 32 bits installer here (to be used on 32 bits systems) : Windows 32 bits version
Beta of Windows 1.9.9 version, 64/32 bits bits installer here (to be used on 64 bits systems) : Windows 64/32 bits version
General publications on the design are available here. A technical paper on new "profiling tools" can be found here.
Old packages: the following packages contain the source code for Linux, OSX and Windows and binary versions for OSX and Windows. A more technical documentation is also included:
jack-1.9.7.tar.bz2 contains the source code only (mainly for Linux users).
jack-1.9.7.tgz contains the source code and binary versions for OSX 32/64 bits and Windows (where an installer is included).
Jackdmp code in now available on Git at:
Getting the sources
and for those with write access: git clone git://github.com/jackaudio/jack2.git
JACK2 "pipelining" experimental version
Jackdmp current implementation allows explicit parallel clients in a graph to be processed on several available CPU at the same time. A typical case is:
We are experimenting with the "pipelining" idea to allow sequential graphs (like in ==> A ==> B ==> out) to be computed on multi-core machines in a more efficient way. The idea is to cut the D driver buffer size into N several sub parts and run the entire graph with N buffers of D/N size, for example: take a driver buffer size of 1024 frames, with N = 4, the graph is processed with buffer of 1024/4 = 256 frames. With the previous graph we have the activation sequence for an entire driver cycle:
The activation model has been generalized a bit to handle this case. There is a new -D parameter in jackdmp command line to specify the value of N. Two new "jack_set_buffer_divisor/jack_get_buffer_divisor" functions have been added in the API to allow dynamic change of the divisor (= N) parameter in a running graph. A corresponding "jack_bufdivisor" client is now compiled.
Testing : the pipelining branch is available here: svn co http://subversion.jackaudio.org/jack/jack2/branches/pipelining
WARNING, WARNING !!
When used with output ports, the "jack_port_get_buffer" function was assuming that the buffer address could be cached by the client. This is not the case anymore in the pipelining branch version. The "jack_port_get_buffer" must now be used each time in the process callback to retrieve the correct buffer address. The consequence of this change is that some very famous jack applications (like Ardour or Hydrogen) get broken! (April 2009 : Ardour 2.8 is now fixed).
The code has been tested on OSX with some heavy CoreAudio jackified applications and the jack DSP load drops as expected as soon as the divisor gets > 1. Typical tests were done with driver buffer size = 512 or 1024 and N = 4 or 8.
When several jack clients are opened in a same process (either the server or a separated process), the cost of context switch between clients can be reduced by replacing the more costly fifo based
client activation system by a more efficient direct call to the client audio Process callback. This is especially interesting when clients are connected in sequence. With the following graph of clients
in a same process: in => [C1 => C2 => C3 => C4] => out,
C1 will be resumed first by the jack server by the standard fifo based system but C2, C3, C4 Process callback will directly be called in C1 Real-Time thread. For any arbitrary graph with possible parallel sub-graph,
the system activates any sequential path in the graph with this direct call method and resume parallel parts using the fifo based activation system.
Jackdmp "direct" experimental version
Results: On a 4 cores Intel Mac Pro running jack at 64 frames with 10 in-process "metro like" clients connected in sequence, with the normal activation scheme jack CPU load is 12% and 4% only with the direct call activation scheme.
Testing : the direct branch is available here: svn co http://subversion.jackaudio.org/jack/jack2/branches/direct. A new -C parameter allows to activate "direct call" mode. By default "direct call" mode is off.