Echo and Latency Test Guide

A reference for the DeskTest.net Echo and Latency Test: the one-page check that plays a chirp through your speakers, listens for it in your microphone, and tells you whether you are echoing on calls. This guide covers how the measurement works, how to read the echo return level and round-trip latency, and how to stop an echo.

Open the Echo and Latency Test →

What does the Echo and Latency Test check?

Echo is the single most common front-desk audio complaint: "you're echoing", "I can hear myself", "there's a delay on your end". It happens when a workstation's microphone re-captures its own loudspeaker - almost always because someone is on speakers instead of a headset. The far end then hears their own voice bounced back a fraction of a second later.

The other desktest audio tools - the Call Readiness Test, Microphone Test, and Speaker Test - only prove that a device exists and produces or captures sound. None of them measure whether your room forms an acoustic loop. This tool does: it measures the echo return level (how loud your own speaker comes back into your mic) and estimates the round-trip audio latency.

How the chirp measurement works

Everything runs in standard browser APIs: getUserMedia for the microphone and the Web Audio API for playback and analysis. No plugin, no extension, no upload, and no network calls at all.

1. Microphone access with cancellation off. Behind a Start button (browsers require a click before granting mic access), the tool requests the microphone with echoCancellation, autoGainControl, and noiseSuppression all set to false. This matters: if the browser's own echo canceller were left on, it would remove the very echo the test is trying to reveal.
2. Emit a chirp, capture the return. The tool builds a short exponential frequency sweep (a "chirp" that slides from 500 Hz up to 5000 Hz), starts recording the microphone, then plays the chirp once through your speakers. It captures about 1.5 seconds of mic audio.
3. Cross-correlate. Because the exact chirp is known, the tool slides it against the recorded signal to find where it best lines up (a cross-correlation). The position of the best match is the round-trip delay; the loudness of the matched return, compared with the quiet moment just before the chirp, is the echo return level. The reported milliseconds have AudioContext.baseLatency and outputLatency subtracted, and are framed as an estimate, not a lab measurement.

When should I run this?

• When someone is told "you're echoing". This is the direct diagnostic. Run it on the workstation that is echoing.
• Before a call from a conference room or shared desk. Speakerphones and open-room setups are the usual culprits; confirm before people are on the line.
• When deciding headset vs. speakers. If the test shows echo on speakers and clean on a headset, that is the case for issuing a headset.
• During ticket triage. Have the user run it and send the Diagnostic Report. It states whether an echo was detected, how strong it was, and the estimated latency.

Reading the results

The test runs three steps, each with a status badge: Pending (gray), Running (yellow), Pass (green), Warn (yellow), or Fail (red).

1. Microphone access and echo setup. Confirms the mic was granted and reports whether echo cancellation, auto gain, and noise suppression were actually turned off. If the browser refused to disable echo cancellation (some do), this step warns, because a hidden echo cannot then be fully ruled out.
2. Chirp emitted and captured. Confirms audio was recorded. If the microphone returned flat silence, this fails as a likely muted mic rather than reporting a false "no echo".
3. Echo and latency analysis. The verdict step. It reports a return match confidence (how clearly the chirp came back), the echo level in decibels above the room noise floor, and the estimated round-trip delay.

The numbers you will see:

The three verdicts

No significant echo (pass)

The microphone did not clearly pick up the speaker chirp. There is little or no acoustic loop, so the far end should not hear themselves. This is the normal result on a headset, and a good result on speakers at a sensible volume. Note that it is a snapshot of the current room and volume - turning the speakers up or moving the mic can still introduce echo later.

Echo detected - likely speakerphone (warn)

The mic clearly re-captured the chirp from the speakers. This is the classic "you're echoing" configuration. The reliable fix is a wired or USB headset, which removes the acoustic path entirely. If you must stay on speakers, lower their volume and move the microphone farther away. Keep your call app's own echo cancellation on - this test disables it on purpose to expose the raw echo, but in a real call the app's canceller is your friend.

Feedback risk (fail)

The chirp returned almost as loudly as it was played. That is the condition that produces howling and severe echo, and the loop can start to squeal. Lower the speaker volume immediately, move the mic away from the speakers, and switch to a headset before your next call.

Why headphones read as "no echo"

With sealed headphones or a headset, the sound goes straight into your ears and never reaches the microphone, so there is no acoustic path and the test correctly reports no echo. The tool tries to detect a headset from the device labels and will say so in the result. This is exactly why headsets are the standard fix for echo: physically, they make the speaker-to-mic loop impossible. If a headset is detected, a clean result is expected regardless of the room.

Privacy: what stays local

Your microphone never leaves this device. The captured audio feeds only the in-memory analysis and is discarded the instant the test finishes - it is never recorded, saved, or transmitted. The microphone track is stopped the moment the test ends, and again on reset and when you leave the page, so the mic indicator turns off. The report contains only device labels, the sample rate, the constraint states, the echo level, and the estimated latency. It never contains any audio. The tool makes no network requests of any kind. View source to verify.

For IT admins

Echo is an ergonomics-and-hardware problem more than a software one, but a few things are worth knowing:

Echo cancellation lives in three places. The OS, the browser, and the call app can each apply acoustic echo cancellation (AEC). This test asks the browser to disable its AEC so the raw room echo is visible; that is why a "no echo" result is most conclusive in Chrome or Edge, which honor the request. Some browsers keep AEC on regardless, and the setup step flags that.

The fix is almost always a headset. For staff who take calls at a shared front desk or on a speakerphone, a wired or USB headset eliminates the acoustic loop at the source. No amount of software AEC is as reliable as removing the path.

Microphone permission is governed at two layers. Per-site browser permission and the OS privacy switch both must allow the browser. Chrome and Edge: AudioCaptureAllowed and AudioCaptureAllowedUrls via GPO or Intune. Firefox: Permissions.Microphone in policies.json. Windows: the Microphone Policy CSP (LetAppsAccessMicrophone).

Latency is an estimate. The round-trip figure includes browser audio buffering and cannot be treated as a precise network or hardware latency. Use it as a relative signal, not an SLA number.

Related

• Echo and Latency Test - the diagnostic itself
• Call Readiness Test Guide - the full pre-call check for camera, mic, speakers, and network
• Microphone Test Guide - a deeper mic-only check with playback
• Speaker Test Guide - a deeper speaker-only check with channel tests
• WebRTC Test Guide - the peer-connection equivalent
• About DeskTest.net