diff options
author | B. Watson <yalhcru@gmail.com> | 2020-01-20 06:51:32 +0700 |
---|---|---|
committer | Willy Sudiarto Raharjo <willysr@slackbuilds.org> | 2020-01-20 06:51:32 +0700 |
commit | 0fa512cd35a56897cb155beddcc087ee3eb12f6c (patch) | |
tree | b135c7e80f032276b6619e77f6b1fd71e2fd2079 /audio/jack/jack2vsjack1.txt | |
parent | 74f1cb8cc7d84e468807ca8872f90d2559aebba6 (diff) |
audio/jack: Added (realtime low-latency sound server).
Signed-off-by: Willy Sudiarto Raharjo <willysr@slackbuilds.org>
Diffstat (limited to 'audio/jack/jack2vsjack1.txt')
-rw-r--r-- | audio/jack/jack2vsjack1.txt | 67 |
1 files changed, 67 insertions, 0 deletions
diff --git a/audio/jack/jack2vsjack1.txt b/audio/jack/jack2vsjack1.txt new file mode 100644 index 0000000000000..df950d807df88 --- /dev/null +++ b/audio/jack/jack2vsjack1.txt @@ -0,0 +1,67 @@ +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. |