RunTheTests
/

Audio Dropout Monitor

Catch the moments your audio thread starves — the cause of most crackles and gaps.

Volume warning

This test plays tones that can be loud and may damage hearing or speakers. Turn your volume down before starting, then raise it gradually.

How this test works

Crackles and gaps usually come from buffer starvation. The audio thread has to keep a buffer filled ahead of real time, and when something takes the processor away — another application, a background tab, a driver hiccup — the buffer empties and you hear it. That starvation is measurable without a microphone: the audio clock is driven by the sound hardware, so comparing how far it advances against how far the wall clock advanced over the same interval exposes every moment the audio thread fell behind. A quiet tone plays throughout rather than nothing at all, because an idle graph gives the browser permission to suspend the audio thread entirely, which would look exactly like the starvation being measured. Any interval where the audio clock loses more than twenty-five milliseconds is recorded with its timestamp, and the run lasts twenty seconds.

What the results mean

Dropouts detected
How many times the audio clock fell more than 25 milliseconds behind real time. Zero is the expected result on a machine that is not busy. One or two on a loaded laptop is ordinary; a steady stream is not.
Longest interruption
The worst single gap. Anything above roughly 20 milliseconds is audible — as a click if it is short, and as a stutter if it is long.
Total audio lost
The interruptions added together. A useful sense of scale: 200 milliseconds spread across a 20-second run is one per cent of the audio simply missing.
Rate
Interruptions per minute, so a 20-second run can be compared against how bad the problem feels over a full track or a long call.

Common problems and fixes

Clean result here, but you still hear crackling
Then the cause is downstream of the browser, which is where most crackling actually lives — Bluetooth, the output device, the cable or the driver. Try a wired output and a different application to narrow which.
Many dropouts while other things are running
That is the finding rather than a flaw in the test. Close the other applications and run it again: a count that falls to zero identifies the culprit precisely, and video calls, games and background builds are the usual ones.
Interruptions appear only on battery
Aggressive power saving throttles the processor, and the audio thread is starved first because it is the smallest consumer. Compare a run on mains against a run on battery to confirm it, then check the power mode.
The test reports interruptions but you switched tabs during it
Run it again in the foreground. Browsers throttle background tabs by design, and that throttling produces exactly the pattern this test looks for — the result would be about the browser's power saving rather than your system.

Frequently asked questions

How can it detect dropouts without listening?

Because the failure happens before the sound leaves the browser. The audio clock advances with the hardware, so when the thread is starved it falls behind the wall clock by exactly the amount of audio that was not produced. Measuring the two clocks against each other catches the starvation at its source, and does so more precisely than a microphone in a room could.

Why play a tone at all?

Because an audio graph with nothing in it can be suspended entirely, and a suspended clock is indistinguishable from a starved one. Something has to be playing for the measurement to mean anything. The tone is quiet and low deliberately — it is there to keep the path awake, not to be listened to.

Would this catch a Bluetooth dropout?

No, and that limit is worth being clear about. A Bluetooth link that stutters is downstream of everything measured here — the browser produced the audio perfectly and the radio lost it. A clean result alongside audible dropouts is itself informative, because it points away from the machine and towards the link.

Is one dropout in twenty seconds a problem?

Usually not. A single interruption is more likely to be an ordinary scheduling hiccup than a fault, and modern systems produce them occasionally under any load. What matters is the pattern: several per minute with nothing else running is a real finding, and one on a busy machine is not.

More in Device