 |
| JACK Architecture |
JACK is system for handling real-time, low latency audio (and
JACK was designed from the ground up for professional audio work, and its design focuses on two key areas: synchronous execution of all clients, and low latency operation.
Traditionally it has been hard if not impossible to write audio applications that can share data with each other. In addition, configuring and managing audio interface hardware has often been one of the most complex aspects of writing audio software. JACK provides a system for freely connecting independent audio data I/O points, thus allowing the audio output from one JACK-savvy application to be sent to the audio input of any other JACK-aware client. The system supports multiple connections to and from any audio I/O points, and all data streams are synchronized to sample-accuracy.
As a sound server, JACK operates between the low-level sound system drivers and any JACK-aware client applications, managing the flow of multiple freely interconnected audio data streams.
Features:
- JACK is free software; you can redistribute it and/or modify it under the terms of the GNU GPL and LGPL licenses as published by the Free Software Foundation, http://www.gnu.org/. The JACK server uses the GPL, as noted in the source file headers. However, the JACK library is licensed under the LGPL, allowing proprietary programs to link with it and use JACK services.
- JACK provides a high level abstraction for programmers that removes the audio interface hardware from the picture and allows them to concentrate on the core functionality of their software.
- JACK allows applications to send and receive audio data to/from each other as well as the audio interface. There is no difference in how an application sends or receives data regardless of whether it comes from/goes to another application or an audio interface.
- On Linux all devices supported by ALSA (PCI, USB and Bluetooth) or FFADO (FireWire) will work with JACK.
- Routing audio from Flash to JACK is possible.
- Routing Gstreamer audio via JACK is possible.
- If you use applications that use the ALSA API for audio I/O and not some intermediate such as GStreamer or PulseAudio, you can still force most of them to route their audio to/from JACK.
- There is NO extra latency caused by using JACK for audio input and output. The only impact of using JACK is a slight increase in the amount of work done by the CPU to process a given chunk of audio.
- An audio app in order to use JACK must be callback-based. This means that it should not block on writes or reads from a PCM device; rather, it should be "driven" by a function that gets called at regular intervals. This is a design decision.
- Although not a requirement, Jack supports any streaming data type, not just audio.
- Applications connected using Jack may have their own graphical interfaces. Jack does not make any specifications as to different GUI toolkits or libraries. As a consequence of this, different parts of a running Jack setup may be spread across multiple processes.
- Jack provides full, sample accurate synchronation.
- To represent audio data, Jack uses 32 bit IEEE floats, normalized to value range [-1,1].
- Only noninterleaved audio streams are supported.
- Jack client may consume or produce multiple data streams.
- It should be possible to connect already running applications.
- It should be possible to add or remove Jack clients while the server is running.
- "Zero-Copy" architecture
- as an API JACK provides many benefits because of its high-level of abstraction:
- no hardware configuration
- no software (driver) configuration
- no format negotiation (all channels are mono, 32 bit floating point)
- no main loop (JACK-managed thread handles it)
- on the other hand:
- requires multi-threaded (lock-free) programming skills
- involves use of a client/server system
- "pull" model is harder for some kinds of apps
