How to Design a Low-Latency Digital Delay Line for Home Studios

If you’ve ever tried to record a vocal track and heard a faint echo of your own voice a split second later, you know why latency matters. In a home studio, every millisecond counts – too much delay and the performance feels disconnected. Below I walk you through a simple, low‑latency digital delay line that you can build with a modest PC or a Raspberry Pi. No fancy DSP board required, just a bit of code and a lot of curiosity.

What is latency and why it matters

Latency is the time it takes for an audio sample to travel from the microphone, through your computer, and back out the speakers. In a live‑play situation, you want that round‑trip to be under about 10 ms; anything higher starts to feel like a laggy video game. Musicians are especially sensitive because they rely on tight timing to stay in the groove.

Measuring latency in a home setup

The easiest way to check your latency is to record a click track, play it back through your interface, and look at the waveform alignment in your DAW. The distance between the original click and the recorded click, divided by the sample rate, gives you the delay in seconds. For example, a 480‑sample gap at 48 kHz equals 10 ms.

Pick the right sample rate and buffer size

Two knobs control the raw speed of your digital delay: the sample rate and the buffer size.

  • Sample rate – Higher rates (96 kHz, 192 kHz) give you finer time resolution, but they also demand more CPU. For most home‑studio work, 48 kHz is a sweet spot.
  • Buffer size – This is the number of samples your audio driver processes at once. Smaller buffers mean lower latency but higher CPU load. A buffer of 64 samples at 48 kHz translates to about 1.3 ms of raw latency, which is usually acceptable.

When you set up your audio interface, start with a 64‑sample buffer and 48 kHz. If you hear clicks or drop‑outs, bump the buffer up to 128 samples. The goal is to stay as low as possible without sacrificing stability.

Building the delay line: a circular buffer

At its core, a digital delay line is just a piece of memory that you write into and read from at different times. The most efficient way to do this is with a circular buffer.

  1. Allocate a buffer – Choose a maximum delay time you might need, say 500 ms. At 48 kHz, that’s 24,000 samples. Allocate an array of that length.
  2. Write pointer – Each incoming sample is stored at the current write index, then the index moves forward. When it reaches the end of the array, it wraps back to zero.
  3. Read pointer – The read index lags behind the write index by the desired delay amount (in samples). It also wraps around the buffer.

Because both pointers move in lockstep, you never need to shift data around; you just wrap. This keeps CPU usage low and guarantees consistent timing.

Simple pseudo‑code

#define MAX_DELAY_MS 500
#define SAMPLE_RATE 48000
#define MAX_DELAY_SAMPLES (MAX_DELAY_MS * SAMPLE_RATE / 1000)

float delayBuffer[MAX_DELAY_SAMPLES];
int writePos = 0;
int readPos = 0;
int currentDelaySamples = 240; // 5 ms delay as an example

void processSample(float in, float *out) {
    // write incoming sample
    delayBuffer[writePos] = in;

    // read delayed sample
    *out = delayBuffer[readPos];

    // advance pointers
    writePos = (writePos + 1) % MAX_DELAY_SAMPLES;
    readPos = (writePos - currentDelaySamples + MAX_DELAY_SAMPLES) % MAX_DELAY_SAMPLES;
}

The key to low latency is to keep currentDelaySamples as small as possible while still achieving the musical effect you want. For a slap‑back echo on a guitar, 80–120 samples (about 2–3 ms) is often enough.

Testing and tweaking

Once you have the code running, listen carefully. A good test is to play a short percussive hit (a snare or a hand clap) and watch the delay tail. If you hear any “grainy” artifacts, you may be hitting the edge of your buffer size or the CPU is struggling with the chosen buffer.

A quick way to verify true latency is to enable “direct monitoring” on your interface (if it has one) and compare the direct signal to the delayed one. The difference you hear is the real‑world latency of your implementation.

Practical tips for the home studio

  • Use integer math when possible – Floating‑point operations are cheap on modern CPUs, but integer math can shave a few microseconds off each sample, which adds up.
  • Avoid unnecessary processing inside the audio callback – Keep the delay line code tight; do any UI updates or file I/O in a separate thread.
  • Consider oversampling for higher quality – If you need a very smooth delay tail, run the delay at twice the sample rate and then down‑sample. This adds a bit of CPU cost but can reduce aliasing.
  • Add a simple low‑pass filter – Real‑world tape delays roll off high frequencies over time. A one‑pole filter after the read pointer gives a more musical sound without much extra work.
  • Save your settings – Store the delay time, feedback amount, and filter cutoff in a small JSON file. That way you can reload the exact same vibe for the next session.

I built my first low‑latency delay line on a Raspberry Pi while recording a folk duo in my living room. The whole thing ran at 48 kHz with a 64‑sample buffer, and the musicians barely noticed any lag. The best part? The code was only a few dozen lines, and the sound was warm enough that I never felt the need to buy a pricey hardware unit.

If you’re curious, the full source code for this tutorial lives on the Signal Delay Lab repository (linked from the blog). Feel free to tweak the parameters, add modulation, or experiment with stereo spreading. The joy of digital delay is that it’s both a technical challenge and a creative playground.

Happy building, and may your mixes stay tight!

Reactions
Do you have any feedback or ideas on how we can improve this page?