Jackdmp for multi-processor machine

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.

jackdmp use a new client activation model that allows simultaneous client execution (on a smp machine) when parallel clients exist in the graph (client that have the same inputs). This activation model allows to better use available CPU on a smp machine, but also works on single-processor machine.
jackdmp use a lock-free way to access (read/write) the client graph, thus allowing connections/disconnection to be done without interrupting the audio stream. The result is that connections/disconnections are glitch-free.
jackdmp can work in 2 different mode at the server level:
- "synchronous" activation : in a given cycle, the server waits for all clients to be finished (similar to normal jackd)
- "asynchronous" activation : in a given cycle, the server does not wait for all clients to be finished and use output buffer computed the previous cycle. The "audible" result of this mode is that if a client is not activated during one cycle, other clients may still run and the resulting audio stream will still be produced (even if its partial in some way). This mode usually result in fewer (less audible) audio glitches in a loaded system.

Belorussian translation here : http://webhostinggeeks.com/science/jackdmp-be

JACK2

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.

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).

Getting the sources

Jackdmp code in now available on SVN at: svn co http://subversion.jackaudio.org/jack/jack2/trunk/jackmp

and for those with write access: svn co svn+ssh://jacksvn@jackaudio.org/jack2/trunk/jackmp

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:

in == > A ==> C ==> out and in == > B ==> C ==> out

A and B depend of the same input (the "in" driver in this case) and can be activated on 2 processors, C waits for A and B outputs.

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:

A(1) <== 1 processor
A(2) B (1) <== 2 processor
A(3) B (2) <== 2 processor
A(4) B (3) <== 2 processor
B(4) <== 1 processor

when X(n) represent the index of the 256 frames buffer used in the processing. Processing can now be done on several cores at the same time.

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

jackd -R -D 4 -d alsa -p 1024 and
jack_bufdivisor 8 to change the divisor value while running.

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.

Jackdmp "direct" experimental version

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.

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.