The 128-Sample Floor: Why a Feedback Loop Has a Minimum Delay

Where I hit it

One sound in my project is a plucked string, made with a method called Karplus–Strong: a burst of noise goes round a short delay loop, and the length of the loop is the pitch. I describe it in Karplus–Strong: How to Pluck a String With a Delay Line.

Low notes are fine. High notes come out at the wrong pitch, because the loop can't be made as short as the note needs.

Why the limit exists

The browser doesn't work out sound one sample at a time. It works in blocks of 128 samples, which the Web Audio specification calls a render quantum.

A feedback loop sends a node's output back to its own input. Inside one block that output doesn't exist yet, so the earliest it can come back is one block later. MDN's page on DelayNode says a cycle must contain at least one DelayNode or the nodes in it are muted. As far as I can tell from the spec, a delay inside a cycle is then held to at least one block, whatever value you give it.

What I did

I drop the note by octaves until it fits. An octave down is the same note, lower, so the harmony survives.

const ceiling = audioCtx.sampleRate / 128;  // highest pitch the loop can reach
let f = wantedFrequency;
while (f > ceiling * 0.95) f /= 2;          // same note, an octave lower, with a margin
delay.delayTime.value = 1 / f;

It is a loop and not a single halving, because one octave down is sometimes still too high. As a side effect the plucks ended up in the low register, where there was more room for them anyway.

The proper way round it

An AudioWorklet lets you write the loop yourself, one sample at a time, with no block limit. That is the right tool if you need high plucked notes. I didn't, so I took the simple route.

Sources

• Web Audio API specification: the 128-frame render quantum
• DelayNode, MDN: a cycle must contain a DelayNode