What browser audio tests can and cannot diagnose

By WaveLocus Editorial · Published undefined

A browser audio test can create a known signal, request microphone access, report some browser-visible settings, and preserve your answers. It can show that a particular path worked or failed under stated conditions. It usually cannot identify a faulty component from one result, measure physical loudness without calibration, certify audio quality, or diagnose hearing.

Separate stimulus, observation, and diagnosis

A stimulus is the signal or request the browser controls, such as a 440 Hz tone, a left-only reference, or a microphone permission request. An observation is what happened, such as the left speaker playing, a meter moving, or a dropout repeating. Diagnosis is the explanation for that result. The first two can be recorded directly. The third normally requires another comparison.

This separation prevents a common mistake. If a left-only reference is heard on the right, the observation is that the current path reverses the audible channel. The result does not establish whether the browser, operating system, interface, adapter, cable, amplifier, or endpoint caused it. A controlled swap is what begins to isolate those possibilities.

Read each browser test at the right level

TestWhat it can supportWhat it cannot establish alone
Basic output toneThe current browser session produced an audible reference through the present path.Calibrated loudness, full frequency response, or health of every component.
Left/right referenceThe audible channel arrived on the side you report.Which stage swapped, mixed, or lost a channel.
Frequency sweep or noiseAn audible change, rattle, or interruption appeared under repeatable settings.A laboratory response curve, hearing threshold, or exact physical cause.
Microphone meterThe permitted input delivered browser-visible samples that changed with sound.Calibrated SPL, flat microphone response, or proof that a conferencing service will use the same device and processing.
Electrical loopbackEligible return-path timing and signal observations under the documented method.Acoustic speaker-to-ear delay, room response, or results outside that hardware path.

Know what the browser can see

For output, the Web Audio specification defines an AudioContext routed toward a real-time output device. The specification also notes that output latency depends on the platform and connected hardware. A generated signal still passes through stages outside the page before becoming sound.

For input, the browser uses media-capture APIs and requires permission. MDN's getUserMedia reference explains the secure-context and permission requirements. Browser-visible track settings can describe items such as sample rate, channel count, and whether processing settings are reported. They do not turn an ordinary microphone into a calibrated sound-level meter.

Use a result as a boundary, not a verdict

A passing output test establishes a useful boundary: sound was produced through this complete path at this time. It does not prove that every application, format, channel, or frequency will work. A failed test also has a boundary. It tells you the current combination failed, not why.

That is why WaveLocus asks for explicit observations and uses terms such as “consistent with,” “possible,” and “check.” Open the basic audio test for an initial output reference, then preserve the result in guided diagnosis. Change one variable, repeat the same reference, and compare. A cause that follows a changed component becomes more plausible, while a cause that stays behind becomes less plausible.

Choose the next test from the failure

  1. No browser sound at all: keep another working application as a contrast and follow the browser-only audio guide.
  2. One side is missing or swapped: use the fixed left/right sequence, record the physical side, and then change one path element.
  3. The microphone meter stays flat: use the microphone test and separate permission, device selection, and incoming signal.
  4. A rattle follows frequency: narrow the trigger with the frequency sweep and a short low-level tone.
  5. You need repeatable timing: use electrical loopback only with an eligible physical return path and the documented method.

Recognize the main sources of uncertainty

The browser is only one stage. Operating-system routing, communications modes, accessibility settings, enhancements, sample-rate conversion, interfaces, wireless transport, amplifiers, cables, speakers, microphones, room acoustics, and user position can all affect a result. Some settings are exposed by APIs, some can only be reported by the user, and others remain hidden.

Microphone permission is also not proof that the intended device was selected or that another application uses the same processing. A microphone meter moving is evidence of received samples, not a guarantee of intelligibility or calibrated level. Similarly, a digital dBFS value describes the signal relative to digital full scale. It is not physical dB SPL. See the level-units guide before interpreting a number as loudness.

Know when you need a different method

Use calibrated measurement equipment and a documented acoustic method when you need physical SPL, defensible speaker response, or certification. Use an audiologist or appropriate clinical service for hearing concerns. Follow the manufacturer's service process when equipment is hot, damaged, smells unusual, or produces severe noise at low level. NIOSH notes that hearing risk depends on loudness, duration, and repetition in its noise guidance.

For support, a careful browser result can still be valuable. Record the device category, browser, operating system, connection, selected input or output, exact test, observation, and one changed variable. Export a structured account through the support evidence pack. A clear reproduction is more useful than an unsupported claim that a particular component is broken.

Next step

Choose the smallest test that answers your immediate question. Record the observation before changing settings, then continue through guided diagnosis. If you need to understand how WaveLocus classifies eligible and limited results, read the measurement methodology.

Sources and method

This guide maps current WaveLocus output, channel, microphone, signal, and loopback workflows to their evidence boundaries. The Web Audio specification documents browser audio graphs and platform-dependent output behaviour. MDN documents microphone capture permissions. NIOSH supports the safety boundary. Browser tests can narrow a signal path, but they cannot replace calibration, clinical assessment, or controlled hardware inspection.

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