[1]Skip navigation. [2]Home [3]applications | [4]developers | [5]documentation | [6]download | [7]email | [8]faq | [9]home User login Username:* _______________ Password:* _______________ Log in * [10]Create new account * [11]Request new password [12]Home JACK FAQ Just what is JACK anyway? JACK is a system for sending audio between applications as well as allowing them to all share an audio interface. Each application is run in exact sample sync with each other, and the entire system is designed to run at very low latencies (as low as your hardware will allow). Read some [13]background How did JACK come to be? People on the linux-audio-dev list saw the need for a server API that would allow high-bandwidth, low-latency communication between a number of audio applications. The proposal that was put forth was called "LAAGA", the Linux Audio Applications Glue API. JACK may be seen as an implementation of these goals. How does JACK compare to...? Please mail the jackit-devel mailing list if you have any concerns about the answers to these questions. Also, no disrespect to any effort is intended, only a recognition of different goals and design principles. Other Linux-centered systems * ALSA: both a HAL and a user-space library for audio under Linux. ALSA is used to provide the default audio i/o driver for JACK. ALSA is a very powerful audio API, but it does not provide a callback-based API or offer any solutions for inter-application communication, though it has been discussed and is theoretically possible. * aRts, a streaming media architecture: aRts was not designed from the ground up with low-latency in mind. Not a fault, but a design decision. A jack output element could be written for aRts, though, as far as I can tell. * GStreamer, another streaming media architecture: GStreamer is designed for in-process construction of media pipelines, and is not used to link applications. JACK elements for GStreamer are under construction. * LADSPA: LADSPA is an internal plugin API for DSP routines, not a way of linking external applications together. Cross-platform systems * PortAudio: a "cross platform, open-source, audio I/O library" offering both callback- and blocking I/O-based APIs. PortAudio backends exist for various Windows, Mac, and Unix HALs. It is mainly focused on hardware I/O rather than a general concept of ports and connections, although a JACK backend to PortAudio is under construction that would allow PortAudio apps to connect to JACK ports. While the JACK API is portable, its current implementation is limited to POSIX-compliant systems; applications needing greater portability might consider PortAudio. In any case, the callback-style API used by both projects makes it easy to port between the two (no pun intended). MacOS- and/or Windows-centered systems * CoreAudio, the Mac OS X audio API: Very similar to JACK in some the sense of being centered on a synchronous-execution-via-callback API, but does not include inter-application audio routing. CoreAudio also includes a hardware-level abstraction layer, whereas JACK uses higher-level drivers for that purpose. The first JACK driver was based on ALSA, but others are available for the OSS and PortAudio interfaces. * ASIO: a HAL for both Windows and MacOS that replaces the native device driver model with something much cleaner. It supports hardware-level latencies, but it does not connect applications to each other. Also, it is subject to license restrictions, and does not exist for Linux (though it would not be impossible to implement it on top of ALSA). * ReWire, an inter-app communications API for Windows and MacOS from PropellerHeads and Steinberg, ReWire is similar in that it provides inter-application audio routing, but does not allow for fully independent processes, and has silly restrictions ("up to 64 channels", etc). JACK also comes without silly license restrictions. * VST, DirectX, MAS, RTAS: these are all Windows/MacOS audio plugin APIs. None of them permit inter-application data sharing. Some plugin hosts can make this possible by using some other system such as ReWire. These APIs also require that the callback you write to process/generate data be executed in the context of the plugin host; JACK allows your callback to be executed within the context of your own application (if you wish to). Doesn't use JACK add latency? There is NO extra latency caused by using JACK for audio input and output. When we say none, we mean absolutely zero. 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, which means that in theory you could not get 100% of the processing power that you might get it if your application(s) used ALSA or CoreAudio directly. However, given that the difference is less than 1%, and that your system will be unstable before you get close to 80% of the theoretical processing power, the effect is completely disregardable. How can I make my app use JACK? Your app must be callback-based. This means that you should not block on writes or reads from a PCM device; rather, you should have your app be "driven" by a function that gets called at regular intervals. This is a design decision. Then, take a look at the simple client code, and do your interesting stuff inside the process() function. Note that code written for any callback API can generally be ported to any other callback API fairly easily. Code that is written around a "blocking I/O" model generally needs to completely redesigned to be used in any kind of callback API. What do I need to do to link to JACK? JACK uses pkg-config. Find a package for your favorite distribution and OS, or build it from source. To build your JACK program, try $ gcc -o myprog `pkg-config --cflags --libs jack` myprog.c This process can be integrated into your autoconf/automake build system with pkg.m4, included in the pkg-config package. Just add the line PKG_CHECK_MODULES(JACK, jack, HAVE_JACK=true, HAVE_JACK=false) to your configure.ac. In addition to HAVE_JACK, the variables JACK_LIBS and JACK_CFLAGS will be created. To substitute on them you will have to AC_SUBST both of them separately. How do I install JACK? Prerequisites * 2.4, 2.5 or 2.6 series kernel with tmpfs turned on (CONFIG_TMPFS) * Shared memory file system mounted on /dev/shm. add the following to /etc/fstab to get it mounted at boot: shmfs /dev/shm shm defaults 0 0 (Note: you may have to make the /dev/shm directory) Once you have the correct shmfs support, you should be able to build jack with the following sequence of commands: sh ./autogen.sh ./configure make make install Good luck! Why are my clients unable to connect to the JACK server? The most common reason is that the server was started using a different user ID. How can I get the best performance out of JACK? "Good performance" for JACK means operating at the lowest latency possible with no dropouts at any load. There are a number of factors which affect performance: * How should I tune my hardware? Sound card Some sound cards are designed better than others. Many "consumer" sound cards use separate internal pointers for capture and playback, which can result in unreliable operation at low latencies. For example, my ens1370 does not operate very well in full-duplex mode. You can work around this by telling the ALSA driver to operate only in capture or playback mode. People have reported problems with ymfpci cards as well. General system configuration People from linux-audio-dev are quite familiar with what is necessary to build a low-latency system. There is no need to rehash all of that here, see the low-latency resource page for more information on getting your system in tune. How should I configure my Linux 2.6 Operating System? Real-time scheduling JACK requires real-time scheduling privileges for reliable, dropout-free operation. The server requests these privileges when running with the -R option. Unmodified 2.6 kernels work much better, but still require special configuration. The simplest, and least-secure way to provide real-time privileges is running jackd as root. This has the disadvantage of also requiring all of JACK clients to run as root. Real-time scheduling is inherently dangerous; a badly or maliciously coded application can hang the system. Worse, running as root gives an intruder too many opportunities to damage or co-opt the entire system by attacking the JACK server or its clients. Systems connected to the Internet would be well-advised to avoid this approach. There are safer ways to gain the needed privileges, the exact method depends on which Operating System you run. Most recent distributions use PAM to manage the permissions of users on a relatively granular level. If the file /etc/security/limits.conf exists on your system, it is using PAM. In order to configure PAM such that normal users can run jackd with realtime privileges make sure the following lines exist: @audio - rtprio 99 @audio - memlock unlimited @audio - nice -19 This assumes that the users that are allowed to run jack are members of the group "audio". If you want to grant this right to one specific user you can replace @audio with the username of that user. Usually the limits.conf file contains some instructions on how to use it. How do I configure Mac OS X? On Mac OS X, all users have real-time privileges. No special tuning is required for real-time scheduling. But, OS X lacks POSIX support for locking pages into real memory. JACK will run without locking memory, but users should avoid running too many other applications when performing critical real-time tasks. If there is too much memory contention, the operating system might page out data needed for the time-critical process cycle, causing dropouts. Mac OS X users should take a look at [14]JackOSX, a set of tools for integrating JACK into the Apple CoreAudio environment. How do I configure other Operating Systems? BSD does not provide any way to grant real-time privileges to non-root users. So, jackd -R only works for the superuser. Some older BSD variants lack POSIX support for locking pages into real memory. JACK will run without locking memory, but users should avoid running too many other applications when performing critical real-time tasks. If there is too much memory contention, the operating system might page out data needed for the time-critical process cycle, causing dropouts. What other software tuning should I consider? The settings for JACK's backend can affect performance to a large degree. Try adjusting the number of periods (anything other than 2 or 3 will probably not help you with JACK). For some cards, using just --playback or just --capture may help. Avoid using a plug-layer PCM device (like default). See the terse ALSA driver help (jackd -d alsa -h) or the jackd man page for a list of options. It has been found that mounting /tmp/jack as tmpfs (in RAM) solves problems that many people have experienced with xruns while using JACK. The solutions below help when your /tmp directory is mounted on a journalled filesystem. Just put this in your /etc/fstab none /tmp/jack tmpfs defaults 0 0 There is also a compile option to enable JACK to place its FIFOs on a ram-based filesystem as follows: # mkdir /mnt/ramfs [edit /etc/fstab and add the following line] none /mnt/ramfs tmpfs defaults 0 0 Then use --with-default-tmpdir=/mnt/ramfs to the JACK configure line when you build it. No clients need to be recompiled. JACK, jackd, libjack, jackit, wha? There is a profusion of names surrounding the JACK project, and hopefully this will help clear things up. JACK JACK is the name of the whole system. It may be written as Jack if you prefer. It is an acronym for "Jack Audio Connection Kit". Do you know JACK? jackd, libjack As a system, JACK has a number of parts. The server process is called jackd, and the library that applications link to is called libjack. From a theoretical perspective, this distinction is not important, but it is helpful to note the difference when describing JACK internals, due to the fact that these components execute in different processes and address spaces. jackit, jack-audio-connection-kit As luck would have it, by the time we got around to registering a sourceforge site for JACK, there was already another program out there by the same name. "jackit" is a play on the original JACK acronym. Not only does that other project have the sourceforge name, it has mandrake and debian packages too, so we needed a new name for releases. At the moment, we are releasing tarballs as jack-audio-connection-kit. >> [15]login or [16]register to post comments [17]applications | [18]developers | [19]documentation | [20]download | [21]email | [22]faq | [23]home Copyright 2001-2006 Paul Davis Ссылки 1. http://jackaudio.org/faq#content 2. http://jackaudio.org/ 3. http://jackaudio.org/applications 4. http://jackaudio.org/developers 5. http://jackaudio.org/documentation 6. http://jackaudio.org/download 7. http://jackaudio.org/email 8. http://jackaudio.org/faq 9. http://jackaudio.org/ 10. http://jackaudio.org/user/register 11. http://jackaudio.org/user/password 12. http://jackaudio.org/ 13. http://jackaudio.org/intro 14. http://jackosx.com/ 15. http://jackaudio.org/user/login?destination=comment%2Freply%2F5%23comment_form 16. http://jackaudio.org/user/register?destination=comment%2Freply%2F5%23comment_form 17. http://jackaudio.org/applications 18. http://jackaudio.org/developers 19. http://jackaudio.org/documentation 20. http://jackaudio.org/download 21. http://jackaudio.org/email 22. http://jackaudio.org/faq 23. http://jackaudio.org/