low-latency mixing: when 93ms matters and when it doesn't

the tracking problem

you are tracking a vocal. you want to hear compression in the headphones while the singer performs. you load your compressor. 93 milliseconds of delay. the singer hears themselves a beat behind. you bypass it. this is the latency problem.

here is what most latency discussions get wrong: they treat latency as one problem. it is two. during mixing, latency is invisible. your DAW compensates for it automatically, shifting every track so they line up perfectly on playback. you could have 200ms of plugin latency on the vocal bus and the mix would still be phase-aligned to the sample. the DAW handles it. you never notice.

during tracking, latency is a disaster. the performer sings into the microphone. the signal travels through the interface, into the DAW, through every plugin on the channel, and back out to the headphones. every millisecond of that round trip is a millisecond the performer hears between the physical act of singing and the sound arriving in their ears. at 93ms, they hear themselves nearly a tenth of a second late. try clapping your hands while hearing the clap 93ms after the impact. it breaks your timing.

this is why spectral plugins live on the mix bus and not on the tracking chain. not because they sound wrong at low latency. because 93ms of monitoring delay makes it physically difficult to perform.

why spectral plugins have latency

a standard EQ or compressor works sample by sample. audio comes in, gets processed, goes out. the delay is a handful of samples at most. your DAW barely notices.

spectral plugins work differently. they need to see a chunk of audio before they can do anything, because they need to decompose that chunk into individual frequencies. the tool they use is the Short-Time Fourier Transform, which converts a window of audio samples into a frequency spectrum. the plugin reads the spectrum, decides which frequencies need processing, applies gain changes per frequency band, and converts back to audio.

the window has to fill before the transform can run. a 4096-sample window at 44.1 kHz takes 92.9 milliseconds to fill. that is the latency, and it is physics rather than sloppiness. the plugin literally cannot know what frequencies are present until enough audio has arrived to measure them.

the window size determines frequency resolution. a 4096-sample window at 44.1 kHz gives you bins roughly 10.8 Hz wide. that is fine enough to distinguish a resonance at 3 kHz from one at 3.01 kHz. shrink the window to 1024 samples and latency drops to 23.2ms, but the bins widen to 43.1 Hz. the plugin can still see broad spectral shapes but loses the precision to separate nearby resonances. it is not a slider you can move for free.

(think of it like a camera exposure. longer exposure captures more light and more detail. shorter exposure freezes motion but the image is noisier. you pick the exposure for the shot.)

how much latency can you actually hear

the question is not whether 93ms is perceptible. it is. the question is where the threshold sits, and the answer depends on who is listening and what they are doing.

Lester and Boley measured monitoring latency with trained musicians in a studio tracking scenario.[^1] their finding: 10ms of steady latency was not rated significantly different from 0ms by most performers. the session felt normal. timing stayed tight. the threshold for noticeable degradation sat somewhere between 10ms and 20ms for the majority of subjects.

McPherson, Jack, and Moro tested digital instrument latency across multiple performer types.[^2] their key insight was that jitter matters more than magnitude. 10ms of steady latency was tolerable. 10ms plus or minus 3ms of jitter was not. the inconsistency broke the performer’s sense of connection to the instrument more than the delay itself did. this matters for plugin chains where buffer sizes fluctuate under CPU load.

Jack, Mehrabi, and McPherson extended the work to perceived instrument quality.[^3] percussionists detected latency at 3-5ms. keyboard players tolerated more. the instrument type and the performer’s training shaped the threshold. but across all subjects, latency below 10-12ms was rated as acceptable for performance.

where does 93ms land? clearly above the threshold. every performer in every study would notice it.

23ms is the harder call, and i am not going to round it in my favour. it sits above the 10-12ms band those studies call comfortable, and just past the 10-20ms window where Lester and Boley saw degradation start. for a percussionist it is well past. the comparison worth making is your own buffer setting: tracking at 512 samples already costs you around 23ms of round trip before a single plugin loads, so LIVE mode roughly doubles a delay most people are working at anyway rather than adding a new order of magnitude to it. 93ms is out of the question for tracking. 23ms is a judgement call, and it is yours to make on your own material.

plugin delay compensation

every modern DAW includes plugin delay compensation. Ableton Live, Logic Pro, Pro Tools, Reaper, Cubase, Studio One. the implementation details differ but the principle is the same: the DAW reads the reported latency of every plugin on every track, finds the highest latency in the session, and delays all other tracks by the difference. the result is sample-accurate alignment on playback.

this works perfectly for mixing. you can stack spectral plugins across your entire session and the mix stays phase-coherent. the DAW adds the delay automatically. you do not need to think about it.

the problem is monitoring. when the singer is performing, the signal travels from the microphone through the interface, into the DAW, through every plugin on the channel strip, and out to the headphones. PDC aligns the recorded audio after the fact. it does not reduce the round-trip monitoring delay the performer hears in real time.

some engineers solve this with direct monitoring: routing the microphone signal straight from the interface to the headphones, bypassing the DAW entirely. this gives near-zero latency but means the performer hears the dry signal with no plugin processing. if you wanted them to hear compression or de-essing while singing, direct monitoring does not help.

the latency landscape in 2026

not all spectral plugins carry the same delay. architecture choices, window sizes, and lookahead buffers vary. here is where the category sits today:

plugin	approach	low-latency mode	standard latency
Soothe 3	per-bin spectral	yes, oeksound describe it as zero latency for tracking	not published
Pro-C 3	broadband + lookahead	0ms with oversampling and maximum lookahead both off	lookahead up to 20ms, plus oversampling latency
DSEQ3	frequency-domain dynamics	seven quality modes from eco eco to ultra 2/3	not published
smart:comp 3	spectral + AI	yes, a Zero-latency Mode	not published
broadband comps	sample-by-sample	n/a	typically near zero
KERN standard	4096 STFT	n/a	~93ms
KERN LIVE	1024 STFT	~23ms	n/a

“not published” means exactly that. i checked oeksound, sonible and TBProAudio on 3 August 2026 and none of them state a latency figure for standard operation, so there is nothing here for me to quote. an earlier version of this table filled those cells in anyway (52ms for Soothe 3, 8 to 557ms for DSEQ3, zero for smart:comp 3) and i could not tell you where those numbers came from. the KERN rows are read straight off setLatencySamples in the source. if latency is the thing your decision turns on, measure it in your own DAW with a null test, because that is the only number that describes your setup.

KERN is not the lowest-latency option. Soothe 3 and smart:comp 3 both ship a zero-latency path, and Pro-C 3 runs at zero with oversampling and maximum lookahead switched off. if latency is the single most important constraint in your workflow, those are strong choices, and i would rather you bought one of them than bought mine and found out.

KERN LIVE at 23ms is a trade-off. it is a quarter of the standard mode. it preserves most of the spectral resolution that makes the standard mode precise. it is nowhere near zero, and i will not frame it as zero. (honesty is cheaper than returns.)

LIVE mode: how it works

toggle LIVE in the plugin UI. the reported latency drops from ~93ms to ~23ms. the spectral display updates to reflect the new resolution. the DAW re-reads the reported latency and adjusts PDC. that is it.

what changes under the hood: the FFT window shrinks from 4096 samples to 1024. the frequency bins widen from ~10 Hz to ~43 Hz. and the LIVE engine drops six of the stages that depend on fine spectral resolution: spectral reassignment, the spectral-flux transient gate, cepstral gain smoothing, the psychoacoustic masking gate, loudness weighting, and salience weighting. the ERB filterbank still runs. the gain smoother still runs. the core per-band processing still happens. the input to each band is coarser and several of the refinements sitting on top of it are gone.

that is a bigger reduction than the word “mode” suggests, and i would rather say so than let you find out on a mix. on a vocal with a narrow 3 kHz resonance, the standard mode can see and suppress a 20 Hz-wide peak. LIVE mode sees the same region as a broader bump and applies a wider cut. the result is slightly less surgical. on a drum bus or a full mix, the difference is smaller because the spectral content is already broad.

right-click the spectrum display and you get an option worth knowing: HQ analysis mode. this runs the full 4096-sample FFT for the visualizer only, while the audio path stays on the fast 1024-sample LIVE engine. you see the full-resolution spectrum while processing at 23ms. useful for spotting narrow problems you want to address after toggling back to standard mode for the mix.

CPU gating ensures only one engine runs at a time. when you toggle between LIVE and standard, a 50ms crossfade blends the two paths so there is no click or dropout. the inactive engine goes dormant.

LIVE mode is available in KERN SMOOTH v1.4.0, KERN WARM v1.5.0, and KERN PUSH v1.1.0. free update for existing license holders.

frequently asked questions

frequently asked questions

how much latency can musicians actually hear?

research shows 10ms steady latency is not significantly different from 0ms for most musicians. percussionists are more sensitive at 3-5ms. 93ms is clearly perceptible but your DAW compensates for it during mixing. the problem is only during tracking, when the performer hears the delay in their headphones.

why do spectral plugins have more latency than EQs or compressors?

spectral plugins use an FFT window to analyze frequency content. the window must fill with audio samples before processing starts. a 4096-sample window at 44.1 kHz takes ~93ms to fill. smaller windows reduce latency but also reduce frequency resolution. standard EQs and compressors work sample-by-sample with no windowing.

what is plugin delay compensation and when does it fail?

your DAW delays all other tracks to match the highest-latency plugin, keeping everything in sync for playback and recording. it works perfectly for mixing. it fails for the performer during tracking because they still hear the delayed signal in their headphones while singing or playing.

does KERN have a low-latency mode?

yes. SMOOTH v1.4.0, WARM v1.5.0, and PUSH v1.1.0 all have an opt-in LIVE mode that drops the reported latency from ~93ms to ~23ms (4096 samples down to 1024, at 44.1 kHz). toggle LIVE in the plugin UI for tracking. toggle it off for mixing to get full spectral resolution.

should i mix with low-latency mode on or off?

off. standard mode uses the full 4096-sample FFT for maximum spectral resolution. LIVE mode trades some resolution for speed. the difference is subtle on most material but matters for critical mixing decisions. use LIVE for tracking, standard for mixing.

references

a note from the developer

a live mixing engineer named Keith wrote to ask if KERN would ever get low-latency. he runs front-of-house for mid-size venues and wanted spectral compression on the vocal bus during the show, not just in the studio after the fact. at 93ms, that was not happening. his monitors would have been nearly a tenth of a second behind the singer’s mouth.

the same week, oeksound shipped Soothe 3 with zero-latency mode. i went back to the DSP literature.[^4] the question was whether a dual-window architecture could give KERN a usable tracking path without gutting the spectral resolution that makes the standard mode precise. the answer was yes, with trade-offs. 1024 samples instead of 4096. coarser bins. some processing stages omitted. 23ms of reported plugin latency instead of 93.

23ms is a long way from zero, and it is above the 10-12ms the research calls comfortable.[^3] Soothe 3 at 0ms is the better latency number, plainly. what 23ms bought was Keith being able to put spectral compression on the vocal bus at a show at all, which 93ms ruled out entirely. that was the bar i set, and it is a lower bar than zero. if what you need is zero, buy the plugin that gives you zero.

i have read where the tracking threshold sits. i have not tracked a drummer through 93 ms and watched it fall apart. if you have, jonas@kernaudio.io.