Echo Test

Introduction

The DeviceHub Echo Test plays a short tone and checks whether your microphone hears it locally, a simple loop presence check entirely in the browser. It is not a network echo canceller trial against a remote peer, and it is not a substitute for acoustic treatment advice. Instead, it answers a practical support question: can this machine’s output and input form a detectable local loop right now? Teachers validating classroom speakers with a USB mic, developers testing getUserMedia plus Web Audio together, and users unsure whether “no echo” means muted speakers or a dead mic benefit from a guided local loop. DeviceHub keeps volume conservative and encourages headphones when possible to reduce feedback risk while still proving the path. Kiosk builders, exam-proctoring helpers, and DIY streamers often need a binary answer: does this PC’s speaker path reach this PC’s microphone right now? DeviceHub’s Echo Test supplies that local loop check without placing a phone call or uploading audio to a TURN server. Clear warnings about feedback keep the tool safe for open offices when users follow headphone guidance. The vocabulary “echo” here means local loop presence, and DeviceHub repeats that definition so searchers expecting Zoom AEC scores are not misled. Clear naming and repeated disclaimers are SEO-honest: people searching for echo tests deserve to know whether a page measures local loops or call-path cancellation before they trust a green checkmark.

What this tool does

The tool requests microphone permission, plays a brief synthesized tone through the default output, and watches input levels or correlation for evidence that the mic captured the burst. On-page status reports success, weak detection, or failure. You control volume and can stop instantly if feedback begins. The check is local only, no call is placed, and no audio is sent to DeviceHub servers. Use Microphone Test when you only need speech levels, and Latency Test when you need a timing estimate rather than a yes/no loop detection. A short tone burst plus input level or correlation watch yields pass, weak, or fail style feedback. Conservative defaults prefer detection at moderate volume over blasting. The test refuses to be marketed as AEC quality scoring; it is presence detection for the local loop only. Weak detection states help distinguish “barely coupled” from “fully silent mic,” which matters when a tone is audible across the room but the selected boom is muted.

When to use it

Run the Echo Test when troubleshooting whether speakers and mics work together before enabling software monitoring, when a kiosk must prove both directions of audio, after docking station changes that sometimes break one path only, and when teaching juniors how getUserMedia and Web Audio interact. Avoid blasting tones in quiet offices, prefer headphones. If you need quantitative delay, switch to Mic Monitoring Delay Estimate after a successful echo detection. Use it when commissioning a new USB cam-mic bar, when a classroom amp was rewired, when confirming a headset boom hears sidetone-capable monitoring, and when teaching getUserMedia+Web Audio integration in workshops. If you need timing numbers after a pass, continue to Mic Monitoring Delay Estimate. Support scripts can ask users to screenshot the pass/fail status instead of describing “I think I heard something,” which reduces ambiguity on remote sessions. Factory burn-in desks for headset assembly can use the pass state as a quick station check before packaging, provided volumes stay controlled and headphones are preferred.

How it works

getUserMedia opens an audioinput stream while an OscillatorNode plays a short burst into the AudioContext destination. An AnalyserNode on the input observes a level spike aligned with playback. Detection thresholds are heuristic: quiet rooms and sealed headphones may need slight volume, while open speakers can feedback if gain is high. The page does not implement WebRTC AEC against a remote peer; “echo” here means local loop verification. HTTPS is required for microphone access. All processing remains in-tab. Playback and capture share the same user session clocks closely enough for coarse detection windows. Noise suppressors may swallow short bursts, temporarily disable them if detection fails despite audible tone. Some laptops duck microphone input when speakers are active (half-duplex behavior); headphones bypass that ducking. Permission must cover microphone; speaker output still needs a gesture. Nothing is streamed off-device. Correlation-style detectors can be fooled by constant tones already playing in another tab; close other audio before running the burst. One-shot bursts reduce feedback risk compared with continuous sweeps during detection. If detection thresholds feel too sensitive in loud rooms, reduce speaker volume rather than raising mic gain into feedback. The goal is coupling proof, not maximum loudness contests.

Step-by-step instructions

1. Prefer headphones to reduce acoustic feedback risk, set a moderate system volume, and open the Echo Test on DeviceHub over HTTPS.
2. Click Start and allow microphone permission so the input side of the local loop can open through getUserMedia.
3. Trigger the short tone burst and watch the status or meter for confirmation that the microphone detected the playback energy.
4. If detection fails, raise volume slightly or move the mic closer to the output driver, then retry once, avoid repeatedly increasing gain into feedback.
5. If a squeal begins, click Stop immediately and lower volume before attempting another trial with headphones.
6. When finished, stop all tracks so the microphone releases and no residual monitoring remains active in the tab. Note whether headphones or open speakers were used during the pass so the next technician understands the coupling path.

Common problems

Failed detection with audible tone often means the selected mic is far from the speaker, levels are too low, or noise suppression in the OS is gating the burst. Feedback means open-loop gain is too high, use headphones. Bluetooth devices may introduce enough delay that a short detection window misses the burst, retry or use Latency Test. Wrong input device selection is common on docks; pick the mic explicitly after permission. Far-field array mics may hear the tone while a muted boom does not, if the wrong device is selected, results confuse everyone. Overly short windows miss Bluetooth-delayed bursts; retry once before raising gain. Feedback means stop, do not “push through” with higher volume. Virtual cables that loop browser output into input will always pass and may not reflect acoustic reality; know your routing graph. Conference-room ceiling mics may detect tones from speakers across the table even when a USB headset mic is selected incorrectly, always verify the device label after permission. Privacy shutters do not affect mics, but hardware mute keys do, look for LED mute on the boom. Duplex restrictions on some USB speakerphones intentionally prevent simultaneous play and capture; those devices may fail a loop check by design.

Privacy explanation

The Echo Test processes microphone samples locally only to detect the tone burst. Audio is not uploaded, recorded for playback later, or transcribed. You start and stop the loop manually. Revoke microphone permission anytime through browser site settings after troubleshooting. Echo detection never uploads the burst or the mic capture. DeviceHub does not retain loop recordings for model training. On shared machines, stop tracks and consider revoking mic permission after the check so the next person gets a clean prompt. Loop audio is ephemeral in memory. DeviceHub does not offer a download of the captured burst because retention is intentionally avoided.