mirror of
https://github.com/Ponce/slackbuilds
synced 2024-11-16 19:50:19 +01:00
67 lines
3.3 KiB
Text
67 lines
3.3 KiB
Text
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.
|