Linux audio: multitrack recording and latency

Linux is often like the disorganized toolbox in you find in somebody's garage. There's lots of useful tools in there somewhere, but first you're going to have dig around, untangle everything, and do a lot of google searches to figure out what it all is and how to use it.

The Linux situation for musicians is no exception.

Lately I've been attempting some simple multitrack recording. I have a portable recorder (Zoom H4n) that works as a 4-track recorder, but the interface (tiny screen, a few buttons and a selection wheel) is a little cramped. And even my simple projects run out of tracks quickly.

So, laptops are supposed to be able to do this, right?

To record, I've got to get audio into the laptop somehow. My options are:

1. laptop audio jack: unlike my old laptops which had multiple audio jacks, this has one which doubles as input and output; it takes a headset with a TRRS jack like you'd use for mobile phones. The output is stereo but the input is only mono, I'd need some sort of adapter, and I have no idea what sort of inputs it'd handle well: mic, instrument, line level?
2. The Zoom H4n: it's not just a recorder, it's also a USB audio interface, so you hoook it up to the laptop with USB, then plug mics or instruments into it.
3. My Zoom B3 bass pedal: this also functions as a USB audio interface. But all I can record with it is bass guitar. (OK, electric guitar or other instruments might work too.)

So, I can transfer some tracks I'd already recorded with the H4n to audacity, plug the B3 into my laptop, plug headphones and bass into the B3, and hit audacity's "record" button. Audacity streams the existing tracks to the B3, so I can hear them over my headphones, and what I play on bass gets sent back to the laptop and audacity puts it in a new track.

Unfortunately, when I play back the result, the timing sounds all wrong--the bass lags noticeably behind the other instruments.

What's happened is that I was playing in pretty good time with what I heard in my headphones. But what I heard had already taken a little while to get from audacity to my ears. And what I played took a little while to make its way back. So, there was a delay. I shifted the track around a little, and with some trial and error got to make it sound OK. But, that's going to be a pain to do every time, so, what to do instead?

Googling around found me a page explaining how to measure and correct for latency with audacity.

I figured I'd first just test the laptop (leaving the B3 aside for now). I plugged my usual phone earbuds into the laptop's audio jack to create a loop, putting the earbuds right next to the mic and turning up volume pretty high. I made a click track in audacity, and hit record. Then I could zoom in on the two tracks and see that the original click track was offset by about 149ms from the recorded track that had been played over the earbuds and come back through their mic. Repeated tests showed anywhere between 145 and 154ms for that round-trip latency.

The page linked above explains how to tell audacity to automatically shift recorded tracks to compensate for a known latency, and it looked like a shift of 150ms would get me within 5ms of where it should be--and people apparently start hearing events as simultaneous when the events are within about 20ms of each other, so 5ms isn't bad. But, I was curious if I could do a little better, so I switched to jack instead--unlike the default audio system on my laptop (pulseaudio), jack is designed for predictable low latency.

This meant opening qjackctl, setting qjackctl->Setup->Device to the B3, starting jack, then starting audacity and making sure its audio device was set to jack. This time three tests got me exactly 33ms each time. Much better--jack makes a big difference!

I tried a similar test with the H4n, this time using a cable from its headphone jack to one of its inputs to create the loop. There was nasty feedback until I realized I needed to turn off the H4n's own monitoring--I didn't want it sending its input straight back through the headphone jack. Then I also needed to set qjackctl->setup->sample rate to 44100. With that done, I measured latencies ranging from 95ms to 271ms. Ugh! There's no way to automatically adjust for that. (Actually, the first three tests gave me 99ms, 97ms, and 95ms--which I could live with--but after more problems recording later I reran tests and found that quickly repeated tests often give similar latencies, but waiting and coming back can a few minutes later can give very different results, for some reason.) Googling around suggests the H4n just isn't a great USB audio interface if you care about latency.

The B3 got me much more consistent results, about 57-60ms.

But that only helps with the bass guitar, so I ordered a USB audio interface that claims good latency (Focusrite Scarlett 2i2). That's predictably getting me 48ms round trip latency.

For multitrack recording purposes, I care more about the variation in latency than the latency itself, so that's good enough for me. But, it might be interesting to see if I can get those numbers a little lower. Most of the remaining latency is probably happening in software running on my laptop, so some careful configuration there might help.

Also I should try learning Ardour, it looks potentially more useful than Audacity. And their approach to latency measurement and compensation looks more sophisticated. Another day!