What five milliseconds feels like

Latency is an abstract number until you’ve felt it.

I spent a year demoing live-performance software at small meet-ups in Prague and Brno, asking producers to play a kick pattern on a borrowed pair of pads through three different apps with the only variable changed being the buffer size. I’d watch their faces. Five milliseconds rolled off them. They played like the pads were directly wired to the speakers. Twelve milliseconds and they’d stop, frown, and ask “is something wrong with this pad?”. Twenty milliseconds and they’d tell me the gear was broken.

The interesting thing was that none of them could tell me the actual number. They didn’t say “12 milliseconds feels late”. They said “the pad isn’t right”. Latency doesn’t feel like delay. It feels like the instrument is dead.

What “5 ms round-trip” means

Round-trip latency is the time between you striking the pad and the sound landing in your ear. It’s the sum of:

• USB MIDI from the controller to the OS (about 1 ms)
• The audio driver waking up your callback (depends on buffer: about 1.3 ms at buffer 64 / 48 kHz)
• LiveSet processing the note, running the engine, mixing, applying FX (about 1 ms)
• The audio driver pushing the buffer out to the interface (another about 1.3 ms)
• The DAC and your speakers (about 1 ms)

That adds up to around 5 ms. The actual number depends on your interface. RME and Universal Audio tend to be the fastest; Behringer UMC is slower but still fine; built-in laptop audio is slower still, often double the number.

The number stops mattering once you can’t feel it. Most working drummers can detect 7-10 ms. Most working DJs can tolerate 15 ms before something feels off. Our 5 ms target is well under both. We hit it because of small choices throughout the engine, not because of any single trick.

What we did to get there

A few things, none of them clever.

We don’t do anything between the audio callback waking up and writing to the output buffer that isn’t audio. No telemetry, no UI updates, no garbage-collection pauses. The callback is the most-protected loop in the codebase. Anything that would block it gets pushed to other threads with lock-free queues.

Every plugin runs in its own sandbox, but we don’t context-switch to call it. The plugin’s audio callback runs in the same thread as ours, scheduled adjacent in the call stack. Sandboxing protects against crashes, not against slow plugins.

The engine never allocates memory during playback. Every buffer it touches is pre-allocated at startup or on plugin scan. If you fire a scene with 12 tracks of fresh audio, the engine doesn’t pause to make room.

Garbage collection isn’t a thing. The audio thread is in plain C-style code with no runtime hooks. We pay the cost of writing it that way. You get a thread that doesn’t stutter.

When the number changes

Three things make your round-trip latency worse than 5 ms.

Bigger buffer. Buffer 64 is the sweet spot, small enough for live work, big enough that the driver doesn’t underrun on a busy CPU. Buffer 128 doubles the buffer latency to about 5.4 ms; buffer 256 doubles it again. We default to 64 on machines we know can handle it.

Slower interface. A USB Class-Compliant cheap interface adds 2-4 ms over a tuned ASIO/Core Audio driver. We list verified interfaces on the system requirements page, they’re the ones we know stay under 5 ms at buffer 64.

Heavy plugin chains. Some plugins are themselves not fast. A Diva running at high-quality oversampling can eat 2-3 ms on a single voice. Stack four of those and your buffer starts to glitch. The Settings panel shows per-track CPU; the worst offenders are obvious.

What this means at a gig

You stop thinking about the rig. The pad lights up the same instant the kick lands in the monitors. The macro knob responds in time with your wrist. The scene fires on the bar, not three buffers after the bar. Every gesture you make feels like it landed.

That’s the deliverable. Five milliseconds is a number. The feeling is that the instrument is alive.