Describe the symptom precisely
Start with a sentence that identifies what feels late. The sound follows the key, the cursor follows the sound, the microphone return follows the voice, or the sequencer becomes uneven when the page is busy. These are different observations. A single latency number cannot explain all of them.
Use a plain sound with a clear onset and disable unnecessary effects for the first comparison. A slow attack or long pre-delay can feel like technical latency even when the event path is responsive. Keep the musical patch available, but establish a simple reference that exposes timing rather than concealing it.
Write down the controller, browser, operating system, audio device and output route. Wired headphones and a wireless listening path are different systems. Change one part at a time and retain the reference sound so each comparison answers a specific question.
Repeat the reference at the beginning and end of the session. This helps reveal whether the surrounding system changed while you were working.
Know what the browser reports
AudioContext exposes several timing-related values with different meanings. MDN describes baseLatency as processing latency between the context’s output and the host audio subsystem, and outputLatency as an estimate associated with the output device. Neither alone measures a complete physical key-to-ear or microphone round trip.
The getOutputTimestamp method relates an audio-context time to an estimated performance-clock time for output. It can help align visual presentation with audio, but it is not a measurement of a finger strike. Keep the clock origins and units explicit when using it. Subtracting unrelated timestamps can produce a precise-looking number with no useful meaning.
Add diagnostic timestamps at the points your application actually observes: receipt of an input event, scheduling of a sound and relevant context state changes. Label them as software observations. If you need an end-to-end measurement, use a suitable external recording or loopback method and document exactly what its start and end represent.
Compare repeated trials rather than one result. A consistent delay and variable timing suggest different problems. Do not describe a system as responsive solely because its best attempt was quick, or as unstable because one unrelated interruption occurred. Preserve enough context to reproduce the condition.
Improve the path that is responsible
If the sound is prompt but the display lags, investigate rendering and visual scheduling before changing audio buffers. If the audio itself glitches under load, inspect processing deadlines and unnecessary work. If a microphone feels doubled, check whether direct and software monitoring are both active before assuming the browser is the sole cause.
Treat latencyHint as a request, not a contractual promise. A lower-latency configuration can make the system more demanding, and the browser or device may choose settings that differ from your preference. Test the resulting behaviour on the intended hardware rather than displaying the requested value as a measured achievement.
Restore the real musical patch one element at a time. Add its envelope, effects and full voice count, listening after each addition. This reveals which delays are artistic and which are technical. A deliberate slow bloom can remain part of the sound while the initial response becomes more immediate.
Finish with a short before-and-after record of the actual problem. Include the reference configuration, the one change that helped and any remaining limitation. A useful diagnosis narrows the uncertainty. It does not need to claim zero latency; it needs to make the instrument’s response consistent enough for a musician to phrase with confidence.
Try this.
Define one timing symptom, build a clear-onset reference and compare one system change at a time. Keep software timestamps distinct from end-to-end measurements and record repeated trials.
Listen back
- Which event is late relative to which other event?
- Does the reported value include the path you care about?
- Is the problem consistent delay or variable timing?