Open the control panel for your interface, set the buffer to 256 samples, and it will tell you something reassuring — 5.3 ms, near enough. Then arm a track, monitor through a plugin and play a line. The gap you feel is about twice that figure, plus a piece you were never shown. Nothing is broken. The panel quoted one leg of a journey that happens twice.
The number on the panel is half the trip
A buffer is a bucket. The converter fills it with samples, hands the full bucket to the computer, and the computer works on that bucket while the next one fills. At 48 kHz, 256 samples is 5.33 ms of audio — 256 divided by 48 000, and nothing more mysterious than that.
Your guitar goes into a bucket on the way in. The plugin's output goes into another one on the way out. The same arithmetic runs twice, so buffering alone costs 10.67 ms before any other part of the chain has done anything at all. The panel shows one direction because one direction is what the setting controls. Your hands sit at the end of both.
What the buffers cannot account for
Loop an interface's output back into its own input with a short cable and measure how long a click takes to come home. That is what a round-trip latency measurement is, and free tools have done it the same way for years: send a pulse, catch it, count the samples in between.
One published set of those measurements makes the point better than any specification sheet. An RME converter running its own driver at 44.1 kHz with a 64-sample buffer measured a round trip of 232 samples — about 5.3 ms. Two 64-sample buffers account for 128 of those samples. The other 104 samples, near enough 2.4 ms, are not buffers at all.
They are the parts of the chain that do not shrink when you drag the buffer slider:
- The converters themselves. Both the analogue-to-digital and digital-to-analogue stages use digital filters that need a run-up of samples before they can produce an output. That cost is fixed by the chip and its filter setting.
- The transport. Audio crosses USB in scheduled packets, and the schedule does not care how small your buffer is.
- The driver's safety offset — extra samples the manufacturer adds so the stream does not break up under load. Well-written drivers keep it small; generic ones do not.
So your delay has two terms, and only one is under your control: a variable part made of two buffers, and a fixed part of a couple of milliseconds belonging to the hardware and its driver.
The driver decides more than the badge does
The fixed part is not a small constant that everyone shares. In the same published session, the same RME hardware on the same machine measured 15.8 ms when driven through the generic ASIO4All wrapper instead of its own driver, and 9.6 ms through a WASAPI-based wrapper — roughly double the native figure. The converters did not change. The code between them and the application did.
Hardware differences are real too, and they sit in the same range. A Focusrite Forte measured at the same 64-sample setting came in near 11.8 ms, against the RME's 5.3. That is a gap of more than six milliseconds attributable to nothing you can set in software.
The practical reading: an interface with a mature manufacturer-written driver beats a nominally faster one running on a generic wrapper, every time. If yours only offers a wrapper driver on your operating system, that has already cost you more than any buffer setting will win back.
What the delay actually does to playing
Delay is not heard, it is felt, and different instruments feel it at very different points. A widely quoted set of tolerances from live-sound practice puts vocalists at under 3 ms, drummers under 6 ms, pianists under 10 ms, guitarists under 12 ms and keyboard players under 20 ms before the delay starts to interfere with placing a note.
Vocalists sit at the top of that list for a physical reason: a singer hears their own voice through the skull as well as through the monitors, so a delayed monitor arrives as a second copy of something the body has already registered.
What people are bad at is noticing a change in delay. In a study of the just-noticeable difference for audio latency, participants needed on average 49 ms of added delay to notice a change from a starting point of zero, and 27 ms from a starting point of 64 ms. The lesson for a buyer: an impression that one interface feels tighter than another is not evidence of a few milliseconds, and a few milliseconds is all that separates most of them.
Cutting the buffer pays less than the slider suggests
Put the two terms together and the arithmetic of tuning becomes clear. Take a typical interface with roughly 2.5 ms of fixed cost, at 48 kHz:
- 256 samples: 10.67 ms of buffering plus the fixed part — about 13 ms round trip.
- 128 samples: 5.33 ms of buffering plus the same fixed part — about 8 ms.
- 64 samples: 2.67 ms of buffering plus the same fixed part — about 5 ms.
- 32 samples: 1.33 ms of buffering plus the same fixed part — about 4 ms.
The first halving buys about 5.3 ms. The second buys 2.7. The third buys 1.3, and by then you are paying for it with CPU load, because the driver has to wake up and complete a full round of processing twice as often. Each halving costs roughly double the interrupt rate and returns half the saving of the one before, and the floor you are approaching is not zero — it is the fixed part.
That is the whole answer to "why does 256 feel late". It is not late because 256 is a large number. It is late because 256 is counted twice and lands on top of a floor you cannot move.
The minute that settles it
Take a short cable, connect output one to input one, and run a free round-trip measurement tool. Note the figure at your usual buffer, then at half that buffer, and subtract. If the difference is close to the buffer arithmetic above, your driver is behaving and your fixed cost is whatever remains. If the difference is much smaller than the arithmetic, something in the chain — a wrapper driver, a hub, a power-saving setting — is adding a fixed cost of its own, and that is the thing worth fixing.
Then decide whether you need the low buffer at all. Most interfaces route the input signal straight to the headphone output in hardware, which bypasses the computer entirely: you hear yourself with no round trip and the buffer becomes irrelevant to your playing. Direct monitoring costs you the ability to hear the plugin while you play, and buys you a stable session at 512 samples with the CPU load of a much larger project.
Which leads to the unpopular recommendation. If you record voice or acoustic instruments and monitor through the hardware, do not pay extra for an interface on the strength of its latency figures — a difference of one or two milliseconds in a round trip you are not using is not worth a penny. Pay extra when you play virtual instruments, where the round trip is unavoidable, and even then buy the driver rather than the badge: the difference between a native driver and a generic wrapper is larger than the difference between two respectable interfaces.
How this was put together
Five independent sources sit under the figures above: published round-trip measurements of an RME converter at a 64-sample buffer, showing 232 samples of total round trip; the same session's figures for generic wrapper drivers on identical hardware, at 15.8 ms and 9.6 ms; a comparable measurement of a Focusrite Forte at 11.8 ms on the same buffer setting; the loopback method itself, as documented by the authors of the free measurement tools and repeated across four buffer sizes in independent testing; the instrument-by-instrument tolerance figures used in live-sound practice; and a peer-reviewed study of the just-noticeable difference for audio latency.
The derived figures are ours: the 10.67 ms of double buffering at 256 samples, the 104 samples of fixed cost extracted from the RME measurement, and the four-step table of what each halving of the buffer actually returns.
