It's the amount of time that it takes from the press/release of the key to trigger the actual sound, and then the actual sound to come out of the speakers. Possibly something like this: http://en.wikipedia.org/wiki/Latency_%28audio%29

And my lame interpretation (which misses important technical aspects and does not give timing for the individual points, but you can imagine them)

   1. User presses key or clicks the mouse.

   2. The keyboard/mouse usb/com sends signal to the OS

   3. The OS sends signal to the listening windows

   4. The browser gets the key/mouse signal

   5. Sends it for handling to the underlying javascript (  guessing here, haven't looked) code

   6. Some decision, calculation is done (wave signal generated?)

   7. The wave is send to the API (web-audio api? again not familiar).

   8. The API is handled by the browser, and possibly each browser has some kind of asynchronous audio processing, maybe relying on a platform specific audio library (DirectX, OpenAL, I dunno really).

   9. This library further might do some pre-mixing, or send it raw to the OS through some other way (write to /dev/dsp? or who knows what)

   10. The OS takes it and queues it to the OS audio manager.

   11. The OS audio manager would pick it up ever 1ms, or every 5ms, or every 15ms, or... you guessed it - who knows :)

   12. The wave is possibly then processed by the AC97, or was it AC79 (not a hardware guy here)

   13. Finally it might came out through cables to your speakers.

   14. Then it has to travel some short amount of space. I hope you are not under water, as this would further reduce the time for the sound to come.

   15. Eventually your ears would hear it, possibly 1/2ms delay for your one of your ears if you are sitting sideways (or maybe less/more).

So from 1 to 15 is the amount of time it takes for you to press the key, and hear the feedback (e.g. the sound).

I hope this might've helped.

I meant I know what latency is as a notion, just haven't measured it and I don't know how-to.

I feel a bit lame for misleading you in writing this whole thing. Sorry. :(

Well - here is how - record with a camera your keypresses mouse-clicks and at the same time record your screen, and what comes out from your speakers.

Then with some AV editing software, you can mark the time you've pressed the keyboard/mouse click, and when the sound came out.

:)

Awesome! Now lets see how we make that a CI test...hm... :D

Really? Is this the way? When you asked me, I started thinking - maybe the latency of the keyboard all the way up to my code is known... in some spec. As well as the latency after. As a matter of fact, I don't have any control of anything before and after, so there should only be something in the pathway under my control, that makes sense to be measured.

I definitely will give this some thought, thanks for asking.

At least in video games, responsiveness is being measured mainly with high-speed cameras ;) - (60fps, e.g. 16ms is good enough sampling rate)

http://www.gamasutra.com/view/feature/3725/measuring_respons...

This by far is most portable, testable and unbiased way of doing it. If you rely on internal measuring then, well.. Actually I don't know how you can do that - for example when the video / audio signal actually leaves is only verifiable with some external equipment... like camera ;)

I would also do something like tap your desk sharply with a pen right before you film the test, and make sure the audio track is aligned with video at that point. I have no idea how accurate A/V syncing is on say a smartphone, but that would be a bummer if that was completely throwing off the test.