The Linux FireWire Record-Now Mini-HowTo for UbuntuStudio

• Note: This guide makes use of a measurement tool called JDelay that generates a quite unpleasant test signal that might damage your speakers or even ears if you're not careful. Pay close attention to disable hardware monitoring whenever using the tool. There are reminders in these steps below, but ensuring the test signal never reaches your speakers or headphones is still your own responsibility, and I don't offer any warranties. Please make sure you understand this; when you do, please continue.

Introduction

If you already have a Linux digital audio workstation with a FireWire interface set up, it is likely that recording works for you, while the sound might be a bit jittery and out of rhythm.

This is because the current Linux FireWire drivers work very well, but have an issue when it comes to their latency being predictable; in other words, your recording software never knows how long it took the sound it is receiving from the microphone membranes to the hard drive, so it can't really align it properly.

While you wait for this to be fixed, you can align your sound by hand and start recording now.

NOTE: This guide has been tested using HARDWARE MONITORING. There is a theoretical suggestion on how to use software monitoring in the appendix, but it is currently not clear how well it works in practice.

Preconditions

This guide assumes you already have a Linux-based digital audio workstation set up, and are using the Jack audio server to connect to your FireWire device. Recording already works, but is jittery or out of sync.

Ardour 2 works particularly well and is used as an example in this guide, but the guide may apply to other recording software as well, as long as you are using the Jack audio server and a FireWire audio interface.

You also need an audio cable to loop an output of your Audio Interface back into an input.

I. Measure your Latency

1. Connect an output of your audio interface directly back to an input with an audio cable.
2. Get JDelay, a Jack latency measurement tool, with your distribution's package management system.
3. Start the Jack audio server.
4. Start JDelay in a terminal. It will start spewing out a message telling you that it can't hear its test signal yet.
5. Connect the output of JDelay to your audio interfaces output channel you connected the cable with in step 1. Connect the input channel you connected to the input of JDelay.

6. Now that you have a complete loop (JDelay -> audio out -> cable -> audio in -> JDelay) it will start giving you the delay ("Round trip latency") of your audio interface, as measured in audio frames.

II. Stabilize the Latency

At this point, it is likely that the latency will fluctuate quite a bit, which is the jitter you were hearing in your recordings presented to you in numbers. You now have proof that you're not rhythmically challenged after all

While it's ok that you will get a different latency every time you start up Jack, this latency cannot suddenly change while you are recording. The current Linux FireWire changed their latency every time you start up Jack, and every time there is a Jack XRun (even those that are so slight they are not normally reported by Jack). You will see these when you get a latency change in JDelay.

In order to get usable results, you need to be able to stay XRun-Free for at least 15 minutes to get good odds of getting a reasonable take.

The first step to take is to get a realtime-kernel. Not a low-latency kernel, and not a pre-emption kernel, but a Realtime-kernel. The most common one features patches by Ingo Molnar and is of the 2.6 series. In Ubuntu Studio, you can do this by adding the following repository to your installation:

deb http://www.texware.it/ubuntu feisty

adding the GPG key, and updating the local APT cache,

wget -q http://www.texware.it/ubuntu/feisty/BBA3222D.gpg -O- | sudo apt-key add -
sudo apt-get update

and install the package

sudo apt-get install linux-realtime

One way to do this is with Synaptic; Go to the System menu in the top left corner, then select Administration and then Synaptic. Enter your user password. When Synaptic has started, select Software Sources in the menu. Go to the Third Party Software tab and select Add... You will be prompted for a 'deb' line, where you can enter the above. Then click the Reload button in the main Synaptic window and search for and install the package linux-realtime. Its dependencies will be installed automatically. As a final step, restart your machine; it will automatically boot into the new realtime kernel.

To find out more information about the Realtime kernel take a look here.

Even so, to stay without the slightest of XRuns it is likely you will have to increase your buffer size as much as you can; 64ms nominal latency is usually a good value.

Finally, Florian Schmidt has a list of excellent latency tips you can try if you are technically minded.

http://tapas.affenbande.org/wordpress/?page_id=40

III. Align your Audio Tracks

Now that you have virtually xrun-free operation, all you need to do is record. Here's how to do it, compensating latency by hand:

1. Shut down hardware monitoring on your card, and start up and connect JDelay. Make a note of the latency. Turn hardware monitoring back on again.
2. Record your track. Keep plugins disabled while you're recording.
3. Turn hardware monitoring back off, and start up and connect JDelay again. If the latency is still the same, you've got a winner. Congratulations! If you don't, you will have to re-record the track. Sorry about that... if this happens too often, improve the performance of your system until it doesn't any more.
4. Use your digital audio workstation's 'nudge' feature to nudge your recording backward by the amount of frames JDelay reported. (Backward means your track will play earlier.)

   In 'Ardour', you do this with the nudge clock: it's a small box with green numbers on the right hand side of the tool bar, with two small arrow buttons to the left of it. First you right click it, and select 'Frames' in the 'Mode' menu. Then you enter the value reported by JDelay here, and click the '<' (left arrow) button.

5. Play your track and see if it sounds as rhythmic as it did playing it. If it does, congratulations, you have a correctly aligned take of your recording.

-- biased content --

If your digital audio workstation doesn't support nudging tracks, this is your opportunity to start using Ardour 2. Not only will you have a quick solution to your current problem, you will also join an amazing community of wonderful people, and be able to witness true dedication and passion, which is as precious as life experience can get. So head over to ardour.org and download your copy of the brand new and polished Ardour 2 for your distribution!

-- end of biased content --

Technical Explanation

Normally, when you record something with a Digital Audio Workstation (DAW), it automagically aligns your tracks according to how long it took you to hear the accompaniment signal (a click sound, what's already recorded, or both), and how long it takes to reach. If you are using hardware monitoring, your sound card feeds you the signal instanteniously (for practical purposes), while your DAW gets it after the one way latency (theoretically 50% of the round trip latency you measured, or the time the signal takes from your Microphone to to the hard drive).

The accompaniment signal also takes a one way latency, from the hard drive through your output to your headphones.

While recording, your DAW needs to wait a full round trip latency until it gets a signal: Out to your headphones, in through you and your microphone. Since the latency information given out by current firewire drivers is zero, you will get a correctly aligned audio track if you compensate by a full round trip latency, which is the same thing measured by JDelay. (In this case, the connection cable takes the place of your headphones, you, and the Mic).

Theoretically, using software monitoring, you should compensate by 50% of the round trip latency; however, you would have to get quite low latency values that still produce no changes in JDelay in order to be able to use it at all. Also, it is not known whether the one-way latency on the way in is the same size as on the way out, or how large the difference is. It is currently not clear if this is practical or not.