Latency compensation and xrun reduction tips

Although latency mostly refers to buffer size which delays immediate feedback of input, there is additional latency due to the basic processing of your audio interface. There is no way to reduce this “loopback” latency, but its existence will affect the timing of recorded overdubs. To address this, you can tell programs what the delay amount is so that compensation can be made, i.e. the recorded audio will be adjusted in time to account for this delay. Software alone cannot discover what the loopback latency is, so the following procedure is needed to determine the amount of compensation required:

You will need a loopback cable capable of connecting your audio device's physical input to its physical output.

1 - Connect your (mic) input to your (headphone) output with the loopback cable

2 - Start JACK with known good settings

3 - Open a terminal and run jack_iodelay. It will print 'Signal below threshold…' until we make the JACK connections

4 - Use Catia or Claudia to connect the system capture_1 to 'jack_delay in' and connect 'jack_delay out' to the system playback_1 port

5 - With both physical and JACK connections made, jack_iodelay should print output such as 'use X for the backend arguments -I and -O'

6 - In the terminal, use ctrl-C to stop jack_iodelay

7 - In Cadence or Claudia, open the JACK settings and enter the value X from jack_iodelay for both the the input and output extra latency values

8 - Engage the new JACK settings with the “Switch Master” button. If you re-run the above test there should be no additional loopback latency.

This information is used to tell programs how to adjust recordings so that the recorded result will line up precisely with how the original performance aligned with the previous tracks.

Because these settings are not saved in the software to go with the interface choice, you'll need to change them every time you switch devices. The easiest way to do this is to have Claudia sessions for each device so all the settings are saved together.

Wifi adapters have been known to cause random xruns. Some laptops have an external hardware switch to disable wifi. Otherwise, uncheck “enable wireless” in the KDE system tray's network control. If primarily using ethernet, consider disabling wifi (aka 802.11 a/b/g/n) in the BIOS or UEFI menu.

In general, avoid running unnecessary, CPU-intensive programs when recording.

Many pop-up ads and popular web sites make use of Adobe Flash. If you have any browser tabs open, it only takes one to be using a little bit of Flash to cause a big loss of CPU, lower latency and more xruns. The easiest way to avoid this is to close any web browsers.

When using Digital Audio Workstations and similar apps such as samplers etc, it is recommended you convert any sound files you wish to import to use the same sample rate as the one you are using for JACK. Many apps let you import and use sound files of different sample rates to the one you are running JACK with but then attempt to resample the audio 'on-the-fly' and this leads to xruns if your CPU cannot keep up.

You can check the sample rate of audio files using your favourite media player such as smplayer (push CTRL+I when playing your file) or VLC (push CTRL+J) or you can find out from the terminal using mediainfo. soundkonverter and XCFA are good tools for batch conversion of audio files.

Open a terminal and run:

cat /proc/interrupts

Ensure that your audio driver is not sharing an IRQ with another device. Fixing this can be as simple as changing which port a USB audio device is using, but otherwise see this guide to fixing IRQ conflicts.