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,
yalhcru@gmail.com) 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.
|
