We measured the latency and here it is

Latency is the first thing a working musician asks about and the last thing most audio software publishes. The usual answer is a buffer-size dropdown and a shrug. This post is the measurement instead, including the cases where we lose.

Every number below is a [placeholder] pending the current measurement run on the shipping builds. What is not a placeholder is the methodology and the shape of the result, which is the part that determines whether you can trust the numbers when they land.

What we measure

Round-trip latency: analog in to analog out, measured with a loopback cable and a physical impulse. Not the buffer size. Not the reported plugin delay compensation. The actual delay between the click going in and the click coming back, measured on the waveform.

We report the full distribution, not an average. Average latency is nearly useless to a player because the thing that ruins a take is the worst case, not the typical one. So: p50, p90, p99, and the maximum observed over a fixed-length run. If p99 is thirty milliseconds worse than p50, you will feel it as inconsistency even though the average looks respectable.

Every run states the sample rate, the buffer size, the host, the interface, the OS, and whether anything else was running. Latency numbers without that context are decoration.

The three paths

Browser (WASM in an AudioWorklet). Your signal goes through the browser's audio input path, into the worklet, through the kernel, and back out through the browser's output path. The kernel's own cost is small and predictable. Almost all of the latency is the browser's I/O plumbing, and it varies by browser and platform more than it varies by anything we control.

Plugin (VST3 in a DAW). Your interface, the host's buffer, our kernel, back out. This is the good path. The kernel is the same compiled DSP as the browser build, and it is running in a host designed for exactly this.

Standalone. The plugin's kernel with our own device handling instead of a host's. Between the two on most machines.

Where we are worse than native C++

Two places, and neither is a rounding error.

The browser path is not competitive with a plugin, and cannot be. The overhead is in the browser's input and output stages, which is why the site never suggests tracking through a browser tab. The browser build is for auditioning, learning, and playing around — it is full quality, it is the same DSP, and it is still not where you record a solo. Anyone telling you their browser plugin has plugin-grade round-trip latency is measuring something other than round-trip latency.

First-use allocation shows up as a spike. Loading an impulse response or a large table allocates the first time it is touched, and that allocation can cost you a dropout if it happens while transport is rolling. It is visible in the tail of the distribution as a p99 that is much worse than p90. That is a real defect, tracked, and fixed by preloading during initialization rather than lazily. Until it is fixed it stays in the known issues of the entries that have it.

There is a third, smaller one: WASM SIMD support varies, and on a target without it, certain kernels cost meaningfully more CPU. That is a throughput problem rather than a latency problem, but it becomes a latency problem at small buffer sizes on a slow machine.

Where we hold up

The plugin path is ordinary. The compiled kernel behaves like the native DSP it is, the timing per block is consistent because the language restrictions forbid the constructs that cause jitter, and there is no measurable penalty from the fact that the source was TypeScript. That is the entire claim, and it is a modest one: the compiler produces normal native code, and normal native code performs normally.

Run it yourself

The measurement harness is in the repository, along with the fixtures. If your numbers differ from ours on the same configuration, that is more interesting to us than agreement, and the issue tracker is the right place for it.

We would rather publish an unflattering number we measured than a flattering one we hoped for.