20200119 bkw: The default jack version on SlackBuilds.org is now 1.9.14, aka JACK2. The old 0.125.0 version (formerly jack-audio-connection-kit) is still available as "jack1". The JACK2 build used to be called "jack2", and has been renamed to simply "jack". SBo maintainers take note: please don't list jack1 in REQUIRES for your builds. If your build really does work only with jack1 and fails with jack, please contact me (B. Watson, urchlay@slackware.uk) and let me know the details. This information might be helpful in understanding the differences between jack and jack1. jack and jack1 are API compatible enough that applications can be built against either, and in fact most (possibly all?) apps can be built against one and run with the other with no problems. jack1 wasn't designed to benefit from multiple CPU cores/threads. It may (or may not) offer slightly better performance on single-core systems. jack no longer supports jack1's "-Z" flag. When using -Xseq with jack, connect your ALSA MIDI devices to the system "MIDI thru" port, then connect that port to the JACK midi capture port. This is an extra step that isn't necessary with jack1. jack stores a persistent "registry" and database in /dev/shm, which is intended to speed up jack startup and allow multiple jack servers on the same host to cooperate. There is one small issue with this: if jackd can't write to /dev/shm/jack_db/, it will fail to start (segfault). If this happens, make sure jackd is not running, and "rm -rf /dev/shm/jack*". This only happens when jackd is used by different users, which means most of us will be unaffected by it. Upstream has been notified, and a fix is being worked on. Original README from the old jack2 package has some possibly outdated info on the differences between 1 and 2: jackdmp (aka JACK2) is a C++ version of the JACK low-latency audio server for multi-processor machines. It is a new implementation of the JACK server core features that aims in removing some limitations of the JACK1 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 a mono-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 modes 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.