Audio measurement guide
Electrical loopback audio latency test: what it measures and when to use it
Learn how a browser electrical loopback test estimates a local round-trip path, what equipment it needs, and which results should stay withheld.
An electrical loopback test is for a specific job: send a known signal from an audio output into a suitable audio input, then measure the returned signal in the same local browser session. It can help estimate the round trip through that selected path. It is not a microphone test, a room measurement, or the converter specification printed by a manufacturer.
Use loopback only with a real electrical return path
You need an output that can safely feed an input, a suitable cable or approved attenuated connection, and a way to select the returning input in the browser. Connect the output electrically to the input. Do not point a speaker at a microphone and call it loopback. Acoustic testing adds the room, speaker, microphone, distance, and sound travel time, so it answers a different question.
Do not connect a headphone or line output directly to an input unless you know the input can accept the level. Keep monitor volume low and use appropriate attenuation when the equipment requires it. If the connection scheme is unfamiliar, damaged, or needs improvised wiring, stop. A missing measurement is safer than damaged equipment.
What the test measures
Open the WaveLocus electrical loopback test. After you select and allow the intended input, confirm that you have made the electrical path, then run the preflight. WaveLocus plays a known local chirp, records its electrical return, and compares the return with the reference across repeated runs. A supported latency result is a local whole-path estimate for that run and setup.
It includes browser audio scheduling, the selected output path, the physical loopback connection, the selected input path, and the capture path visible to the browser. It does not isolate the latency of a DAC, ADC, interface, driver, operating system, or cable on its own. Change any of those elements and you have a new path that deserves a new run.
Why browser latency numbers are not the same thing
Browsers may expose an AudioContext base latency. MDN describes it as processing latency from the end of the Web Audio graph into the host audio subsystem. That is useful context, but it is not an end-to-end electrical round-trip measurement. A browser can also apply a requested latency hint differently depending on the implementation and device.
An electrical return gives the test a real observed arrival to correlate with the reference. Even then, the number is conditional. Signal level, clipping, channel support, capture processing, noisy returns, and weak correlation can make a metric unsuitable. The correct result in those cases is limited, unavailable, or invalid, not a confident-looking number.
Run a careful preflight
- Document the path. Note the source device, browser, output, input, interface, cable or attenuator, sample-rate setting if exposed, and whether the connection is direct.
- Connect and select one return input. Keep the expected output and input fixed. Browser device names may only become available after you grant input permission.
- Confirm the electrical path honestly. The confirmation is a safeguard, not a technical measurement. Do not confirm it for an acoustic speaker-to-microphone setup.
- Run repeated local trials. Use the default repeated runs first. A group of similar valid trials is more useful than one isolated number.
- Read eligibility before the headline metric. Check the stated reasons, settings, correlation, return level, and any withheld measurements. Preserve those conditions with the result.
Interpret the result in context
Compare only like with like. A useful before-and-after test keeps the same browser, output, input, cabling, signal path, method version, and repeated-run setting while changing one intended variable. Comparing a laptop headphone jack to a USB interface may be useful, but label it as a comparison of two complete paths. Do not attribute the difference to one component without more controlled evidence.
Know what else the preflight can report
The loopback workflow may report return level, polarity, channel capability, noise floor, clipping, frequency-response range, crosstalk, dropout stability, or experimental distortion eligibility. Each is conditional on the same captured return and stated method rules. A level shown in dBFS is a digital full-scale reference, not a sound-pressure measurement. A response range is relative to this local loopback setup, not a calibration certificate.
Browser media settings can also affect a capture path. MDN's media-capture constraints and settings guide explains that available settings depend on the browser and input hardware. Treat displayed echo cancellation, noise suppression, auto gain, channel count, and capture latency as session evidence. They do not describe every hidden part of an audio driver or interface.
When loopback is the wrong test
Use a different workflow if your question is about speaker sound in a room, headphone comfort, whether left and right are audible, microphone permission, or a delay you experience through a calling service. Use the speaker test, left/right test, microphone test, or the relevant application's own documented test instead. Electrical loopback is deliberately narrow because a narrowly defined measurement is easier to reproduce.
WaveLocus performs the measurement locally. It does not upload the recorded return. Its automated validation is not a substitute for physical validation across every interface, browser, and operating system. Do not use one local result as public benchmark data or as proof of a device defect.
Next step
Save the exact path and eligibility statement, then use guided diagnosis if you are comparing a working and failing setup. For a repeatable record, pair the result with the published electrical loopback protocol. The next useful test changes one documented variable, not the whole setup.
Sources and method
This guide describes WaveLocus's local electrical loopback method and its eligibility-led result handling. See MDN's AudioContext baseLatency reference for the browser-side latency concept and its media-capture settings guide for input variability. The guide does not claim calibration, a manufacturer specification, or a measurement where the return cannot be validated.