Device diagnostics research

What a Browser Microphone Test Can and Cannot Prove

Audio testing feels direct: play a sound, record it, and see whether the recording contains it. In practice the browser holds several switches that change the signal before it is measured, and those switches are on by default for good reasons. Our evidence file records each constraint that alters the result, so a test can describe what it measured rather than what it intended.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

A page plays a tone and the microphone picks something up. What has actually been proven about the speakers?

This research explains the browser audio constraints that affect a speaker and microphone test, using a derived definition set. It does not report a measured result for any device and does not certify audio hardware.

Try it on the anchor product: BeanNest Tools /sound-test/, BeanNest Tools /device/.

Echo cancellation removes the test signal

Echo cancellation exists to stop a remote caller hearing themselves. It works by removing from the microphone input any audio the page is currently playing. A speaker test that plays a tone and records the microphone is asking the browser to delete the very signal it wants to detect.

Noise suppression can treat a tone as noise

Noise suppression is tuned to remove steady background sound. A sustained test tone is steady sound. Depending on the implementation, it can be suppressed or attenuated, which makes the measured level an unreliable indicator of speaker output.

Auto gain control invalidates level comparison

Automatic gain control adjusts the input level to keep speech audible. That means any measured amplitude reflects the gain the browser chose, not the loudness at the microphone. Level comparisons between two runs are therefore not comparable unless the control is disabled.

Sample rate resampling moves the peak

A driver can resample the input stream, which shifts where a tone's energy appears in the spectrum. A test relying on finding a peak at an exact frequency can report failure when the audio was in fact present.

The loopback problem is structural

A browser cannot capture system output. Loopback is an operating-system capability. Without a loopback device, a page can confirm that an input device delivers audio and can show its level and spectrum, but it cannot prove that the sound it played reached the microphone through the speakers.

The claim that remains supportable

The supportable claim is that an input device delivered audio at a measured level with stated constraints applied. That is a real and useful check. Asserting that the speakers worked requires either a loopback device or a human confirming they heard the tone, and our guides say which of those they relied on.

Why the constraints exist at all

Echo cancellation, noise suppression, and automatic gain control exist because a typical call would otherwise be unusable: the far end would hear themselves, background hum would dominate, and quiet and loud speakers would be equally hard to hear. The defaults are correct for conversation and wrong for measurement, which is why the guide treats them as properties to be understood rather than as faults to be worked around.

How to get closer to a real loopback test

A user can request the constraints be disabled, and a browser may honour that request. Even then the page cannot capture system output, so the microphone must still hear the speakers through the air. The resulting test proves that audio left the speakers, travelled through the room, and reached the microphone, which is a stronger claim than an input-only check while remaining weaker than a true digital loopback.

Why an analyser can still be useful

An analyser node gives the page a spectrum and a level for whatever reaches the microphone. That is enough to show whether a tone is present and roughly where its energy sits. It is not enough to compare loudness between devices, because the gain control may have moved. Used with that limit stated, the spectrum is a legitimate diagnostic rather than an overclaim.

What only the operating system can do

A true loopback device lets software capture the exact digital stream that would have gone to the speakers, with no acoustic path and no room effects. That capability belongs to the operating system audio stack, not to the browser. Any page that claims a digital loopback result is either using a system device the user configured or is reporting something weaker than it says.

Why the default constraints are correct for conversation

A call without echo cancellation would return the far end's voice to them, without noise suppression would carry room hum, and without automatic gain would make quiet and loud speakers equally hard to hear. The defaults exist because the common case is conversation, and the guide treats them as correct defaults rather than as obstacles. The problem is only that they are wrong for measurement, which is a different job.

How a user can request different constraints

A page can ask for specific constraint values when it opens a stream, and a browser may honour the request. A measurement can therefore request that echo cancellation, noise suppression, and automatic gain be disabled. The browser may still adjust the request, which is why reading back the negotiated settings is part of the procedure, exactly as it is for video frame rate in the adjacent guide.

What an acoustic loopback can and cannot prove

If the page plays a tone, the microphone hears it through the room, and the analyser shows energy at the expected frequency, then audio left the speakers, travelled acoustically, and reached the microphone. That is a genuine end-to-end check and it is meaningful. It is still weaker than a digital loopback, because room acoustics, microphone placement, and any remaining processing all sit in the path.

Why an analyser is the right output

A spectrum and a level are what a diagnostic can honestly present. They show whether signal is present and roughly where its energy sits, which is enough to answer whether the input path works. They are not enough to compare loudness between devices, because gain may have moved, and the guide states that limit rather than presenting the level as an absolute measurement.

What only the operating system can provide

Capturing the exact digital stream that would have gone to the speakers requires a loopback device provided by the operating system audio stack. No browser can create one, so any page claiming a digital loopback result is either using a device the user configured or reporting something weaker than it says. Naming that boundary is what keeps a useful page from overstating what it proved.

How the constraints map onto a measurement

Each processing stage removes or alters information the measurement would need. Echo cancellation removes the played signal, noise suppression attenuates steady tones, automatic gain changes the level, and resampling moves the spectral peak. That mapping is the reason the guide lists them individually rather than as a general caution, because each one breaks a different part of the measurement.

Why reading back the settings matters here too

As with video constraints, a requested audio constraint may be adjusted before it takes effect. Reading the track settings after the stream opens shows what was actually applied, which is what makes a result interpretable. A measurement that assumed its requests were honoured could attribute a constraint's effect to the device.

What a spectrum can and cannot show

A spectrum shows which frequencies carry energy and how much, which is enough to see whether a test tone arrived and roughly how loud it was. It cannot support a loudness comparison between devices when gain may have moved, and it cannot distinguish a tone that travelled through the air from one introduced elsewhere in the chain by another application. Both limits are stated rather than left implicit.

How to interpret a passing result

A passing result means the input path delivered audio at the expected frequency while a tone was playing. It is consistent with the speakers working and it does not prove that they did, because the signal could have reached the microphone by another route. The guide states this so a user treats a pass as evidence rather than as a certificate.

First-party evidence and provenance

How we checked this

We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script in this repository. The definitions file is regenerated by running that script. For this guide we enumerated the Web audio constraints that alter a captured signal and identified which of them remove the very signal a speaker loopback test depends on.

Method: We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script in this repository. The definitions file is regenerated by running that script.
Environment: Node.js on a desktop workstation. The evidence is a definition set with recorded reasons, not a hardware measurement on a specific device.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

tools/research-evidence/device/definitions-2026-09-20.json
tools/research-evidence/device/README.md