How to Use This Page
This page covers the most common problems users encounter when running the Sound Latency Test — including failed tests, unexpectedly high results, zero or near-zero results, and results that vary excessively between runs. Work through the section that matches your situation. If your problem is not listed here, use the Contact page to submit a technical question.
For background on how the test works and what a normal result looks like for your hardware type, see the How It Works page.
The Test Will Not Start
Problem: The browser asks for microphone permission but the test does not proceed after I click Allow.
This is almost always caused by one of three things:
- Another application is holding exclusive access to the microphone. On Windows, applications such as Discord, Zoom, Teams, or OBS can hold the audio device in exclusive mode, preventing the browser from opening a new input stream. Close all other applications that use the microphone and reload the page.
- The browser has been previously denied microphone permission for this site. If you clicked Block on a previous visit, the browser will not re-prompt. To reset: in Chrome, click the lock icon in the address bar → Site settings → Microphone → Allow. In Firefox, click the lock icon → Connection secure → More information → Permissions → Use the Microphone → Allow. In Safari, go to Safari → Settings → Websites → Microphone → find soundlatencytest.com → Allow.
- A system-level privacy setting is blocking browser microphone access. On Windows 11/10, go to Settings → Privacy and Security → Microphone → ensure “Let apps access your microphone” is On and your browser is listed as allowed. On macOS, go to System Settings → Privacy and Security → Microphone → ensure your browser is ticked.
Problem: The test starts but freezes or never displays a result.
The most likely cause is that the tone burst played but the microphone did not capture it clearly enough for the cross-correlation to find a reliable peak. This can happen when:
- The system output volume is set very low — the emitted tone does not register above the microphone noise floor
- Headphones with very good passive isolation prevent the tone from being picked up by an internal microphone
- An external microphone is positioned too far from the output source
- Heavy OS audio processing (noise suppression set to aggressive) suppresses the tone burst in the captured signal
Fix: Increase system output volume to at least 50%. If you are using closed-back headphones with an internal laptop microphone, try using the laptop speakers instead for the test. Disable noise suppression in your OS audio settings temporarily for the duration of the test.
Result Is Unexpectedly High
Problem: My result is over 150 ms and I am not using Bluetooth.
Results above 150 ms on wired audio are typically caused by one or more of the following:
Large OS audio buffer size. On Windows, the default WASAPI shared mode buffer is set by the audio driver and can be as large as 100 ms on some systems. Open your audio interface control panel or Windows Sound settings → Properties → Advanced → Default Format and check whether exclusive mode is available. Installing ASIO4ALL (for consumer audio hardware) or the manufacturer’s ASIO driver (for professional interfaces) can reduce this significantly.
Browser audio processing. Chrome applies echo cancellation and noise suppression to microphone input by default, which adds processing delay. To disable these for testing: in Chrome, navigate to chrome://flags and search for “audio” — disable hardware echo cancellation if available. Alternatively, using Firefox, which handles audio processing differently, may produce a lower result on the same hardware.
Conflicting audio drivers. On Windows, having both a generic Windows audio driver and a manufacturer driver installed for the same device can cause the OS to route audio through an unexpected path. Open Device Manager → Sound, video and game controllers — ensure only one driver is active for your primary audio device.
Problem: My result is 200 ms or higher and I am using Bluetooth headphones.
This is expected. Bluetooth audio codecs introduce encoding on the output side and decoding on the input side. Combined codec overhead for a full round-trip is:
| Codec | Typical Round-Trip Overhead |
|---|---|
| SBC (standard Bluetooth) | 150–300 ms |
| AAC | 100–200 ms |
| aptX | 80–150 ms |
| aptX Low Latency | 40–80 ms |
| LDAC | 80–200 ms (quality-dependent) |
For a meaningful measurement of your audio system’s base software latency, connect wired headphones or use your built-in speakers and retest.
Result Is Unexpectedly Low
Problem: My result is under 5 ms and I am using built-in laptop audio.
A result under 5 ms on built-in laptop audio almost certainly reflects hardware-level zero-latency monitoring rather than true software round-trip latency. Some audio interfaces and certain laptop audio chipsets route the input signal directly to the output at the hardware level, bypassing the OS and browser audio stack entirely. The browser-based tool measures the software path only — if the audio takes a hardware shortcut, the measured figure does not represent the latency your DAW or browser audio application experiences.
If you are evaluating your setup for DAW monitoring or Web Audio API development, the relevant figure is the software round-trip latency. Disable hardware monitoring in your interface control panel and retest.
Problem: My result is 0 ms or negative.
A zero or negative result indicates that the cross-correlation analysis found its peak before the tone burst was nominally scheduled to play — which is not physically possible and indicates a timing reference error. This can occur when:
- The AudioContext clock and the system clock have desynchronised, which can happen on certain browser versions after the browser has been open for an extended period
- The test ran while the browser tab was backgrounded or throttled by the OS
- A browser extension is interfering with Web Audio API timing
Fix: Close all other browser tabs, disable extensions temporarily (especially audio-related or ad-blocking extensions), reload the page, and run the test again in a foregrounded tab. If the problem persists, try a different browser.
Result Varies Too Much Between Runs
Problem: My results vary by more than 15 ms between consecutive runs.
Run-to-run variation of 2–8 ms is normal. Variation above 15 ms consistently indicates audio pipeline instability. The most common causes:
Background applications competing for audio device access. Communication applications, media players, browser-based audio tools in other tabs, and system notification sounds can all interrupt the audio pipeline mid-test. Close all non-essential applications and browser tabs and retest.
OS power management interfering with audio processing. On laptops, Windows power-saving modes can throttle the CPU mid-test, causing audio buffer underruns that shift the timing reference. Set your power plan to High Performance during the test.
Driver instability. Outdated or conflicting audio drivers on Windows are a frequent cause of latency jitter. Update your audio driver from the manufacturer’s website (not via Windows Update, which often installs generic drivers) and retest.
Microphone-Specific Problems
Problem: The test completes but my result seems much higher than expected for my audio interface.
Check whether your audio interface is set to its low-latency driver mode. Most professional audio interfaces offer both a standard class-compliant USB mode and a dedicated low-latency mode (ASIO on Windows, Core Audio on macOS). In standard USB mode, the interface behaves like a consumer audio device and OS buffer sizes apply. In ASIO/Core Audio mode, the driver communicates directly with the hardware at the buffer size you configure in the interface control panel.
If your interface is set to USB class-compliant mode, switching to its dedicated driver and setting a 128 or 256 sample buffer size will typically reduce your round-trip result from 40–80 ms to 5–15 ms.
Problem: The test works on desktop but fails on my phone.
Mobile browsers have more restrictive Web Audio API implementations than desktop browsers. Microphone access on iOS Safari requires a user gesture to unlock the AudioContext, and iOS applies additional audio processing that can interfere with the cross-correlation signal. Android Chrome generally works well but is subject to the same OS audio buffer size limitations as desktop Windows.
For the most reliable latency measurement, running the test on a desktop or laptop browser is recommended. Mobile results should be treated as indicative rather than precise.
Still Having Problems?
If none of the above resolves your issue, the FAQ covers additional questions about result interpretation and measurement accuracy. For problems not addressed in either page, contact Jackson Cooper directly via the Contact page with the following information:
- Your browser name and version
- Your operating system and version
- Your audio hardware (built-in, USB interface, or Bluetooth — and the model if known)
- The result you are seeing (or a description of what the test does instead of completing)
- Whether the problem is consistent or intermittent
Response time for technical issues: 24–48 hours.
Written by Jackson Cooper, founder of SoundLatencyTest.com. Last updated: June 2026.