How we test

Every reading on this site is produced by the Web Audio API running in your browser. That has two consequences we treat as design principles: your audio never leaves your device, and some things genuinely cannot be measured from a web page— where that's the case, we say so on the tool instead of faking a number. This page documents how each reading is computed, where the thresholds come from, and each measurement's limits.

Output tests (speakers, headphones)

• Channel testsgenerate live signals routed through a StereoPanner — every bench plays a short synthesized melody, an octave higher on the right, so the two sides differ in register and a mono-summed system can't fool you. The oscilloscope displays the browser-generated signal before the operating-system and hardware path.
• Phase check plays 200 Hz on both channels, in phase and then with one side inverted. The listener records whether the stereo image changes as expected. Mono summing, spatial processing and the listening environment can affect the response, so it is a diagnostic comparison, not an automatic wiring verdict.
• Frequency limits use exponential sweeps (150→20 Hz, 8→20 kHz). Your tap timestamps the sweep position — the reading is “where you stopped hearing it”, which necessarily mixes hardware response with your hearing. We label it accordingly.
• Surround: we read the audio context's maxChannelCount, which is the maximum capability exposed to the page, then rely on the listener to confirm each channel. It is not automatic discovery of the physical room layout.

Input tests (microphone)

Every microphone metricderives from one primitive: an analyser node exposes 2048-sample frames of the time-domain waveform, and each frame's RMS — the square root of the mean of the squared samples — is converted to dBFS as 20 · log₁₀(RMS). Windowed measurements (noise floor, speech level) average one reading every 50 ms in the energy domain — linear power, mean, back to dB — so one keyboard click doesn't masquerade as your noise floor.

• Noise flooris the energy-averaged level of a multi-second quiet window, taken after the input chain settles (gain control and suppression adapt during a stream's first moments). With browser processing on it describes call-path readiness, not laboratory self-noise — a suppressor muting room hiss yields a floor far below what the capsule picks up.
• SNRis the speech-window level minus the noise-window level, both energy-averaged — the chain's unknown absolute gain cancels out. Talk during the quiet phase and the number is meaningless.
• Clipping: every sample in every analysed frame is checked against |amplitude| ≥ 0.99 of full scale. Analyser frames can overlap the same audio and double-count, so we report “clipping observed” with the session peak rather than a hardware sample percentage.
• Processing chain: the echoCancellation, noiseSuppression and autoGainControlstates are read from the track settings the browser reports after constraints are applied — the browser's claim, not an acoustic measurement; OS or firmware processing can exist that the browser never reports. Informational, since calls want the chain on, recording usually off.

Why dBFS is not SPL — and why we never claim calibration

dBFS (decibels relative to full scale) measures where a signal sits inside the digital capture path: 0 dBFS is the largest value the stream can represent, and every reading counts down from that ceiling. dB SPL (sound pressure level) measures physical loudness in the air. Converting between them requires the microphone's sensitivity, every gain stage the operating system applies, and an acoustic calibration against a known reference — none of which a web page can read. That is why every level on this site is reported in dBFS and never presented as room loudness. A browser meter can tell you your voice sits 40 dB above your room's noise floor; it cannot tell you whether that room measures 40 or 60 dB SPL. Any website showing an uncalibrated microphone reading labeled “dB SPL” is guessing.

Where the thresholds come from

The pass/warn bands on our tools are practical reference points drawn from common broadcast and VoIP practice, not citations of a formal standard — no browser measurement satisfies the conditions a standards document assumes, so quoting one would be theater. Each band has a plain rationale. The speech target of −30 to −15 dBFS leaves headroom below the ceiling while staying well above typical processed noise floors: quieter, and receiving software must apply heavy makeup gain, which raises noise with it; hotter, and peaks start reaching the ceiling, where distortion is permanent. For SNR, above 40 dB a noise suppressor has almost nothing to do; 25–40 dB is unremarkable call-quality territory; below 15 dB a suppressor must guess which energy is voice, and the guessing is audible. Clipping has the one genuinely hard threshold in digital audio — full scale — so it is the only check we treat as binary.

Why the same microphone reads differently in another browser

The browser sits between the hardware and the measurement, and browsers differ. Chrome, Safari, and Firefox make different default choices about sample rate and buffer handling, support different subsets of the processing constraints, and ship different implementations of those processors — two browsers can both report noise suppression “on” and attenuate your room by different amounts. The operating system may insert its own processing (voice isolation, communications-device ducking) that no browser reports, and a Bluetooth headset may switch to a lower-quality bidirectional codec the moment the microphone opens. None of this makes the readings useless — it makes them relative. Compare readings taken on the same device, in the same browser, with the same processing settings, and treat cross-browser deltas as information about the software chain, not the microphone.

Latency

Acoustic loopback: five 2 kHz clicks scheduled on the audio clock and detected on the microphone against a per-run noise floor. The result includes the combined browser output, device, air and microphone input path. The dedicated latency tool reports the median and run-to-run spread; the optional headphone-bench row shows the median only. We do not infer a Bluetooth codec from either result.

Scores

Report scores start at 100 and subtract fixed penalties per failed (25) and warned (8–10) parameter, floored above zero. A score is shown only when that workflow's required checks are complete; partial reports show tested-versus-total coverage instead. Scores are fixed browser-diagnostic heuristics, not calibrated device grades. The individual readings, listener responses and stated test scope are the primary result.

What the shareable report encodes — and what it can't prove

A SoundTestLab report is a client-generated snapshot compressed into the link itself: the readings with their reference ranges and verdicts, the score, tested-versus-total coverage, a coarse platform label (on the order of “macOS · Chrome”), and a client-stamped timestamp. There is no server-side record — the result exists only in the URL, and the decoder validates structure and ranges before rendering anything. That design has an honest ceiling: because the report is generated in the browser, the link proves that a client produced this snapshot, not that a particular device passed a test. It is not hardware certification, it cannot attest that the quiet phase was actually quiet, and a sufficiently motivated person could construct a link by hand. Read it the way you'd read a colleague's console output: a diagnostic note for troubleshooting together, not a certificate.

What a browser cannot measure — so we don't

• Absolute SPL without device-specific calibration — our level meter reports relative dBFS instead.
• Objective headphone frequency response (needs a measurement mic and a fixture).
• Dolby Atmos renderer status, exact Bluetooth codec, or system volume position.
• Anything while the tab is closed. Obviously. But you'd be surprised what some sites imply.

Privacy as measurement policy

Microphone streams are analyzed in memory frame-by-frame and discarded; recordings (voice recorder, mic playback) are held as local browser objects and are released when replaced or when the tab closes; shareable reports are encoded into the URL — we run no database of results. Anyone with a report link can read the encoded snapshot. The Permissions-Policy header pins microphone access to this origin, so no embedded third-party content (including ads) can request it.

Everything above is checkable: the arithmetic reproduces with a few lines against the same Web Audio analyser, and the reported track settings are visible in your browser's developer tools. If our description and your observation disagree, tell us via the contact page.