What browser microphone processing settings actually tell you

By WaveLocus Editorial · Published September 2026

“Echo cancellation on” is a setting, not a verdict that your call is echo-free. The same applies to noise suppression and automatic gain control. If a browser test shows these values, first distinguish what the page requested from what the captured microphone track reports. Then make a short local recording or a controlled call comparison to investigate the sound you actually care about.

Requested is different from reported

A website can ask the browser for a microphone with particular processing choices. The browser negotiates a track with the device and platform, and the page can read some current values with MediaStreamTrack.getSettings(). MDN distinguishes these current settings from the constraints that the page requested. A request for “off” is not evidence that “off” was applied.

The WaveLocus microphone test requests echo cancellation, noise suppression and auto gain control off. After you allow the selected input, its “Actual input settings” panel reports what the browser exposes for that track. The result may read on, off or unknown. Unknown means the page cannot establish the setting from the available browser information. It does not mean off.

What the three labels describe

SettingWhat a reported on state meansWhat it does not prove
Echo cancellationThe current track reports the feature enabled to reduce playback sound returning through the mic.That another person hears no echo in a particular call.
Noise suppressionThe current track reports noise-suppression processing enabled.That speech is clear or every background sound is removed.
Auto gain controlThe current track reports automatic gain control enabled.That the level is comfortable, unclipped or stable in every app.

MDN documents the echo-cancellation, noise-suppression and auto-gain properties as values on a captured audio track. Their presence and values depend on the browser and device. A supported constraint means the browser understands the request; it does not guarantee that the resulting sound meets your expectations. MDN's supported-constraints reference makes that distinction useful.

Check a real concern without creating feedback

  1. Choose one input. In WaveLocus, select the microphone you intend to use. Grant permission only if you are comfortable testing that input. Note its name and the three reported settings.
  2. Speak normally. Watch the meter for signal and clipping. A moving meter confirms capture level in this browser path, not clear speech or a successful call.
  3. Make a short local recording if needed. WaveLocus offers a recording of up to 10 seconds for playback in your browser. Stop capture before listening. Do not play live mic audio through speakers, which can cause feedback.
  4. Compare the same use case elsewhere. If the concern happens only in a meeting app, test that app using its own input and output controls. Keep the same microphone and listening environment where possible. The app may request or apply different processing.

For example, if the WaveLocus track reports echo cancellation off and a call echoes, that setting alone does not establish why the call echoes. The call-echo guide helps distinguish which participant hears the return and which path to change. If the mic meter is flat, begin with the microphone permission and input guide instead of interpreting processing flags on a silent path.

What can change between tests?

Another browser, call service or device can use a different capture track and different requested constraints. A headset may also change its playback behavior when microphone capture begins. Use the headset test if you hear a before-and-during change. Record the browser-reported settings from that test, but describe the sound change as an observation, not as proof of a Bluetooth profile or codec. The page cannot read every hidden part of the operating system's audio path.

If a value is absent, do not infer that processing is absent. If “off” is reported, do not infer that the raw microphone hardware has no other processing. The browser reports its current track configuration, not a laboratory measurement of acoustic suppression or the exact sound delivered to every remote participant. For formal electrical loopback, WaveLocus treats unknown or active processing as an eligibility concern rather than quietly assuming a clean return.

Keep the useful result

Write down the selected input, browser, observed setting values, meter or recording result, and whether the concern repeats in the actual call application. That is enough for a focused next experiment. You can carry the difference into guided diagnosis. Do not share a private recording merely because it exists. If the call fails but the local track looks normal, compare the call app's chosen microphone and processing before changing hardware.

Sources and method

This guide interprets the WaveLocus local microphone settings panel. MDN explains capture constraints and settings and the current-track report. No acoustic suppression performance, remote call quality or hardware certification is claimed.

Next steps

Use the same reference, change one thing at a time, and preserve what the result can and cannot show.

Start guided diagnosisBrowse all guides