JACK (JACK Audio Connection Kit)

• JACK is a low-latency audio server. To adress the soundcard (driver), JACK can use the ALSA system (but also other backend systems like OSS f.e.). But it provides additional features that are missing from ALSA. One of this features is synchronization. When applications make use of the JACK server, they are able to run in exact sync with each other. This means that you can push the 'play' button in one program, and a second program will start playing in exact sync with the first one. Another important feature of JACK, is that it provides a way to route audio (and now also midi) between various applications (inter-application routing). When a program connects to JACK, it gets assigned a number of 'ports'. And these input and output ports can be connected freely with each other. You can connect one output port to multiple input ports, or you can connect multiple output ports to one input port. This makes it possible to make very complex connection schemes between programs. Apart from this, JACK makes it possible to connect multiple programs to the same audio interface. You can use the outputs and inputs of the audio interface as any other output or input ports.
• The command you use to startup the JACK server is jackd. The "d" suffix stands for "daemon". A daemon is a program that is normally run in the 'background', and this means it is not under the direct control of the user. A daemon is typically a program that has to run continuously, so that other programs can connect to it at all times. The jackd command accepts a great number of options to configure the server (man jackd). We will discuss a number of these in a moment.
• Qjackctl is a GUI program, which can be used to control the JACK server graphically. When you start it up (Applications -> Sound & Video -> Audio Production -> JACK control), you will see a control panel with a number of buttons, and a display in the middle. The buttons in the top row speak for themselves, 'Start' and 'Stop' can be used to start/stop the JACK daemon. The 'Quit' button will stop the daemon, and quit from qjackctl as well. In the next row, you have three more buttons: 'Messages', 'Status' and 'Setup'. These buttons open up a new window when you click on them. In the Messages window, you can see which command was used to startup the JACK daemon, and all the messages jackd produces while it is running. If you have problems with JACK, this is the place to figure out what's wrong. The 'Status' button, gives you an overview of the present state of the JACK daemon. Most of the things you can see in this window are also visible in the main display of qjackctl. We will see what most of these entries mean when we discuss the next button. The last button in this row is the 'Setup' button. It opens up a window with four tabs, and the first tab is called 'Setting'. In this window, you can control all the options (and the command itself) that will be used when the JACK daemon is started. I will give you an overview of the most important options and their meanings.
  • 'Realtime': when this option is switched on, JACK will run with realtime priority. We will see later what this means.
  • 'Priority': with this option, you can set the 'realtime priority' with which the JACK daemon will run. A higher number means higher priority. When you leave it at 'default', JACK will run with a priority of 10. You can set it between 1 and 89. If you want to use the default, put it back at 0[1].
  • 'Frames/Period' & 'Periods/Buffer': a soundcard uses a buffer to store the incoming or outgoing samples in. This buffer is a circular buffer (ring buffer), which means that if you reach the end of the buffer, reading or writing will continue from the beginning. The buffer is normally divided in transfer units, called 'Periods'. Whenever the transfer of one period is complete, the hardware will signal the CPU with an IRQ (interrupt request), and applications can act accordingly (read/write another period). So if you divide the same buffer in more periods, the CPU will have to do more work for the same audio stream. The default value for 'Periods/Buffer' will be 2 (the minimum value). Depending on the soundcard, you will be able to set this higher. It is important to understand that the total size of the buffer depends on the product of the size one period (Frames/Period)[2] and the number of periods used per buffer (Periods/Buffer). So if you want to double the number of periods, but keep the buffer size the same, you have to half the size of one period (otherwise the buffer will be twice as big). The total size of the buffer determines the output latency (how long before the signal will reach the output of the soundcard). The size of one period determines the input latency (how long before the signal at the input of the card can be used). If you want to record audio, you should try to set 'Frames/Period' as low as possible (minimum is 64), to get a minimal delay between what you play and what you hear. You can set it to a higher value again when you are mixing, and you want to have more CPU power for other things (f.e. effect plugins). When this value is too low, jack will report 'xruns'. An xrun can be due to a 'buffer overrun' or a 'buffer underrun'. An overrun can happen during recording, and means that the buffer is overwritten with new data, before the application got a chance to use it. An underrun can happen during playback when the application is not quick enough to fill the buffer.
  • 'Sample Rate' & 'Word Length': these should be set to a value your soundcard supports. When an analogue signal is converted into a digital one, the signal is sampled (recorded) at a specific rate. If you use a sample rate of 44100 Hz for example, one second of audio will be represented by 44100 samples (recorded values). Besides the sample rate, there is another parameter that influences the conversion of analogue audio. This is the number of bits used to represent one sample. The more bits you use, the more different values are allowed to describe the value of one sample. This is also called the 'amplitude resolution' (also 'bit depth' or 'word length'), because the value of a sample determines how loud it will be.
• There are a lot more configuration options you can set with the 'Setup' button. But now I would like to continue with the bottom row of buttons in qjackctl. They are called 'Connect', 'Patchbay' and 'About'. When you click the 'Connect' button, you will get a new window with three tabs: 'Audio', 'Midi' and 'Alsa':
  • The 'Audio' tab shows all the audio ports of the clients that are connected to JACK. On the left side, you will see all the output ports of the clients, on the right side you will see the input ports. In addition to the client ports, you will also see output and input ports called "system". The system output ports correspond to the input connectors of your soundcard. The system input ports correspond to the outputs of your soundcard. You can select an output and an input port, and use the 'Connect' and 'Disconnect' buttons to connect the chosen ports.
  • The 'ALSA' tab will show you all the ports and connections of the ALSA sequencer clients. You can connect/disconnect clients in the same way as in the 'Audio' tab.
  • The 'MIDI' tab will show you the clients that use the JACK midi functionality. This is a recent addition to JACK, and it should provide better (sample accurate) MIDI timing for applications. Not many applications make use of JACK midi at this time. An example of an program with JACK midi support is the "non-sequencer".
• In the 'Connect' window you can see all the connections that are currently in use, and you can change the connections while the audio and midi programs are running. But JACK won't remember the changes you've made in this window. This is what you can do in the 'Patchbay' window. When you press the 'New' button in this window, a new patchbay definition will be made in which you will see all current clients and connections (audio and midi). There are two rows of buttons called 'Add', 'Edit', 'Copy', and 'Remove', one for the output sockets, and one for the input sockets. When you press 'Add', you will get a new window describing your new socket. In this window, you can give it your own name, choose it's type (audio or midi), choose the client (you can choose clients that are currently seen by the JACK daemon, or the ALSA sequencer), and choose the channels of that client you want to use (called plugs). Now you can connect your new socket with others. There is a button called 'Save' with which you can save your patchbay definition, and a button called 'Load' to load an existing one into JACK. Whenever you start up an application which has connections described in a loaded patchbay definition, the application will be connected accordingly. This way, you only have to make your connections once, save them, and load them whenever you want to use those connections.
• realtime scheduling && the realtime preemption patch:
  • On the Linux System, the kernel organizes which task should be run at a specific time. This is called scheduling, and there are different mechanisms available in the kernel to organize this.
  • First of all, every process has a 'normal' priority. This priority is changed dynamically by the kernel. You can influence the priority of every process indirectly with the 'nice' value of that process. Processes with lower nice values will be given more CPU time (i.e. they are less 'nice' to other processes) than processes with higher values. Nice values range from -20 to 19, and the default value given to a process is 0. Only root can lower the nice value to less then 0. You can use the 'nice' command to startup a program with a different nice value, and 'renice' to change the nice value of a running program (or process).
  • When the kernel is configured for realtime scheduling, processes can have a realtime priority value as well. A process with realtime priority will always be served before processes without realtime priority. In addition, the process is able to use the CPU as long as it needs (unless it is preempted by a realtime process with higher priority), and it is responsable for releasing the CPU again, so that other processes get a chance to run. Realtime priority values range from 0 to 99 (or 1 to 100). Processes with higher values will be run before processes with lower values. Originally, only the root user was able to run a process with realtime priority. But over time, a number of mechanisms were developed to give normal users this possibility as well. With earlier kernels the 'realtime-lsm' module was used. When this module was loaded, you could give a group on the system the right to run programs with realtime priorities. This method is now depreciated, and replaced with a different (and more flexible) method. This method makes use of PAM (pluggable authentication modules). PAM is used on many Linux systems to provide a common interface to different authentication methods (authentication is about login mechanisms, passwords etc.). PAM has a number of configuration files, and an important one for our purpose is "/etc/security/limits.conf". This file imposes limits upon users or groups on the system, and one of these limits is the maximum realtime priority a user or group can get. Other useful limits for audio work are the minimum nice value (maximum priority) and the maximum size of memory that can be locked. An example of a "limits.conf" file could be:
    @audio   -   rtprio    99
    @audio   -   nice      -19
    @audio   -   memlock   512000
    Here we are specifying certain limits for the audio group (@ means group, if you leave it out the limit will apply to a user). With this file, users that are part of the audio group will be able to run programs with maximum realtime priority, maximum nice priority, and a maximum memlock size of 512000 Kb.
  • The Kernel that is used by Ubuntu Studio, has been patched with the realtime preemption patch (from Ingo Molnar). A kernel patch is a piece of source code that can be merged with the source code of the original kernel. In this way new functionality can be added to the kernel, or existing functionality can be changed. One of the problems with realtime scheduling is that interrupt requests (IRQ's) can still have a higher priority than processes with realtime priorities. IRQ's are signals send by hardware (e.g. when data is arriving from the outside world), and the CPU responds to them by calling the appropriate interrupt handler routines. With the realtime preemption patch, the interrupt handlers are visible as normal processes (with commands like 'ps' and 'top') and they can be assigned realtime priorities. This makes it possible to give certain interrupt handlers a lower priority than a 'normal' realtime process (for example the JACK daemon), or you could give the interrupt handler for your soundcard a higher priority than all the other interrupt handlers. To change the realtime priority of a process you can use the 'chrt' command. You will find more tips and information on assigning realtime priorities to different audio processes on this site: http://tapas.affenbande.org. There is also a package called "rtirq" which can be used to set the realtime priorities of the IRQ handler threads when your system boots. You can get it for Ubuntu Studio from http://archive.ematech.fr/.

[1]

Actually, realtime priority ranges from 0 to 99. If you set the priority to 89, JACK will have one of its threads running at 99. You can see the realtime priority of all threads on your system with 'ps -eLo command,rtprio'

[2]

A 'frame' means one sample value for all the channels in use. For a stereo signal that means one for the left side, and one for the right.