An audio reaction time test measures your response to a sound, with your audio and input devices in the loop. Use it to build a repeatable baseline, not to assign yourself a universal reflex grade. The browser can schedule a cue; it cannot verify the exact instant that sound reaches your ears.
Run the audio reaction time test, then use the average and consistency together. Keep the output device, cue, volume, and response method unchanged when you repeat it.
What an audio reaction time test measures
WiredReflex schedules each sound with Web Audio and maps its audio-clock time to an estimated output
timestamp on the browser's performance clock. It uses getOutputTimestamp() when usable, otherwise
a fallback estimate. Your response comes from the input event's own timestamp, not the time the
handler finishes. The reaction time is the difference between those timestamps, not a direct
measurement of acoustic arrival or neural processing. The measurement methodology
explains this boundary.
Each run has 10 randomized cue opportunities and no catch trials. A press during the cue's waiting period or before its estimated onset voids that cue as a false start. You can finish for practice, but ranking requires all 10 cues clean; a missed cue also leaves the run incomplete for ranking. One false start does not itself establish cheating. Wait for the sound rather than trying to predict it.
How to read your audio result
| Result | What to use it for |
|---|---|
| Average (ms) | The main audio score and leaderboard ranking measure. Lower means faster measured responses on that setup. |
| Best (ms) | Your fastest valid click, not a stable baseline by itself. |
| Consistency (SD) | Spread between responses in milliseconds. Lower means less variation within that run, not necessarily faster responses. |
| Audio points | An app score blending cue scores, best speed, and regularity. It is not your population percentile and does not determine rank. |
| Audio timing context | Observed, coarse, or unresolved clock readings and estimated mapping or interruption warnings. These are diagnostics, not a numerical error bound or acoustic calibration. |
Read the average alongside SD and the trial strip. A single slow response affects the average; a false start or miss means the remaining responses do not represent a complete, rankable run. Do not compare a partial practice average with a clean 10-cue baseline. Neither a low SD nor a small browser-reported output delay proves that your headphones have little delay.
How to run a clean audio test
- Preview a cue at a comfortable, clearly audible volume. Finish a practice run before recording a baseline; do not raise the volume to chase a score.
- Keep the same computer or phone, browser, input device, and response method. Do not mix mouse clicks, touch taps, and keyboard responses in one comparison.
- Keep the same output device, connection mode, cue, and volume. Prefer wired output for a starting baseline, while remembering that wired does not mean delay-free.
- Keep the tab visible and distractions low. If the audio path reports an interruption, note it and repeat the run rather than interpreting it as a change in your reactions.
- Record three complete 10-cue runs with a short break between them. Keep every clean-run average and SD, not just the fastest run. Note false starts and misses separately; restart for a rankable run.
- Repeat the same procedure another day before calling a small difference an improvement. Log the setup and any changed settings so a device change is not mistaken for a personal change.
Three runs is a practical starting log, not a validated sample size or a confidence threshold. Look at the range of run averages as well as each run's SD. If the difference you care about is similar to the variation between your repeats, the result is inconclusive; collect more same-setup runs rather than selecting the best attempt.
For a deliberate sound-response practice block, open the audio test again, preview at a comfortable volume, and choose when to Start. Repeating or practicing does not require public ranking or research donation. Keep this simple sound task separate from visual aim drills and from recognizing meaningful game sounds; no transfer is established by a lower average.
The audio latency stack
Precise scheduling is not the same as verified sound arrival. The Web Audio specification defines a clock-to-output timestamp estimate. It does not make the web page an acoustic sensor.
| Layer | What to keep in mind |
|---|---|
| Browser timing | The audio clock must be mapped to the input-event clock; a fallback mapping remains an estimate. |
| Operating system and output device | Buffering and processing depend on the active path. A reported output-delay value is not an end-to-end calibration. |
| Wired, USB, speakers, or wireless | Treat each device and connection mode as a separate baseline; a connection label alone does not establish its delay. |
| Bluetooth | Hidden buffering or codec delay can affect the result. There is no single correction to subtract from every Bluetooth score. |
| Input device | The response timestamp still comes through a mouse, keyboard, or touch path; keep that path fixed too. |
Audio results therefore remain relative. To compare wired and wireless setups, change only the output path and alternate their order over repeated runs. A persistent gap describes your measured response under those conditions, not the headset's isolated latency: attention, practice, and input variation are still involved. Follow the fuller wired vs wireless comparison protocol.
Why audio reaction time is often faster than visual reaction time
In Jain et al. (2015), 120 medical students aged 18–20 responded faster to a beep than a visual stimulus. That study recorded the fastest of five readings, not a 10-cue average. Its participants, apparatus, and scoring do not establish a universal target for this browser test.
Your audio result need not beat your visual result. Output delay and the different test protocols can change their ordering. Build separate baselines; see visual vs auditory reaction time for comparison limits.
Audio reaction time for gaming
Detecting one known sound is narrower than recognizing a footstep, locating an opponent, or choosing an action. Use this test to track simple sound responses on your setup, not to predict match outcomes. Keep cue choice and volume stable; the Bluetooth guide covers output-path cautions.
Why WiredReflex keeps the warning visible
The output-delay readout describes what the browser reports, not everything it cannot observe. An unreported value is not zero delay. Privacy protections can standardize latency values and reduce clock precision; a lower reading in another browser does not establish a faster or more accurate audio path. Firefox-family timing may use a qualified fallback estimate rather than the output timestamp pair. Even an apparently small reading does not verify physical sound arrival, and a leaderboard place is not a population percentile or a clinical assessment.
For the full modality map, start at the reaction time test hub. For visual screen reflexes, use the visual reaction time test guide.
Sources & context
- W3C Web Audio:
getOutputTimestamp()defines the estimated output timestamp and its mapping to the performance clock. - MDN:
AudioContext.outputLatencydescribes a device-dependent output-latency estimate, not an acoustic calibration. - Mozilla: Resist Fingerprinting explains reduced clock precision and standardized audio latency. Do not disable privacy protections merely to obtain a lower or more precise-looking test result.
- Jain et al., 2015 is the scoped auditory/visual comparison above, not a source of universal browser-score norms.
- How we measure documents WiredReflex's timing estimates, result limits, and ranking rules.