Measuring absolute button latency by sound - Overclock.net - An Overclocking Community

Forum Jump: 

Measuring absolute button latency by sound

Reply
 
Thread Tools
post #1 of 22 (permalink) Old 10-20-2019, 02:58 PM - Thread Starter
New to Overclock.net
 
M1st's Avatar
 
Join Date: Jun 2015
Posts: 809
Rep: 35 (Unique: 27)
Measuring absolute button latency by sound

Basically what i did is i made a script in AHK that produces bleep sounds from pc speaker every time i press M1. Then i recorded all that with ordinary microphone, then used audacity's spectrogram view to measure delay between mouse button's "snap" sound and the bleep.

This is how it looks in spectrogram:

Click image for larger version

Name:	untitled.PNG
Views:	21
Size:	239.8 KB
ID:	301446
Then i switched to duration at the bottom of interface and selected area from the start of click to start of bleep. And it showed the duration in ms. It is that easy actually.

I only tested Kana v2 so far, which is supposed to be +12ms from Ikari, and these are delays i got:

17
17
15
20
18
17
21
14
20
21
15
17
21
19

The fact that there is 14ms absolute delay in one try could mean that Ikari would have 2ms absolute lag there.

The script (also remaps RMB to act as LMB to get normal clicks without bleeping):

Code:
#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

LButton::
SoundBeep , 737, 50

RButton::
MouseClick
M1st is online now  
Sponsored Links
Advertisement
 
post #2 of 22 (permalink) Old 10-20-2019, 04:11 PM
New to Overclock.net
 
munchzilla's Avatar
 
Join Date: Jun 2014
Posts: 1,893
Rep: 59 (Unique: 50)
hey this is really cool. great idea.

how is this affected by things such as DPC latency and other possible causes of input latency? I'm guessing monitor latency doesn't affect anything though - but sound card buffering and such could be a thing if you're not using directstream or asio or something right? unless those latencies are miniscule. I honestly don't know what I'm talking about but just curious how much this would play a role if I wanted to try it out myself.

thanks for sharing.
munchzilla is offline  
post #3 of 22 (permalink) Old 10-20-2019, 04:17 PM - Thread Starter
New to Overclock.net
 
M1st's Avatar
 
Join Date: Jun 2015
Posts: 809
Rep: 35 (Unique: 27)
Quote: Originally Posted by munchzilla View Post
how is this affected by things such as DPC latency and other possible causes of input latency? I'm guessing monitor latency doesn't affect anything though - but sound card buffering and such could be a thing if you're not using directstream or asio or something right? unless those latencies are miniscule. I honestly don't know what I'm talking about but just curious how much this would play a role if I wanted to try it out myself.
I don't know much about it myself, i'm just using on-board audio. I'd appreciate if someone who actually knows it could chime in.

Also if input lag of recording is stable over time, it shouldn't matter since PC speaker (not speakers) is used for making sounds. I don't think it's even connected to audio card.
M1st is online now  
Sponsored Links
Advertisement
 
post #4 of 22 (permalink) Old 10-20-2019, 04:55 PM
New to Overclock.net
 
munchzilla's Avatar
 
Join Date: Jun 2014
Posts: 1,893
Rep: 59 (Unique: 50)
Quote: Originally Posted by M1st View Post
I don't know much about it myself, i'm just using on-board audio. I'd appreciate if someone who actually knows it could chime in.

Also if input lag of recording is stable over time, it shouldn't matter since PC speaker (not speakers) is used for making sounds. I don't think it's even connected to audio card.
ohhh that kind of speaker! that makes sense... I don't have one of those unfortunately... but that's cool too!
munchzilla is offline  
post #5 of 22 (permalink) Old 10-20-2019, 05:06 PM - Thread Starter
New to Overclock.net
 
M1st's Avatar
 
Join Date: Jun 2015
Posts: 809
Rep: 35 (Unique: 27)
Quote: Originally Posted by munchzilla View Post
ohhh that kind of speaker! that makes sense... I don't have one of those unfortunately... but that's cool too!
Well, it's possible to modify the script to play sound through normal speakers instead.

You can swap the SoundBeep line with SoundPlay, Filename.
M1st is online now  
post #6 of 22 (permalink) Old 10-20-2019, 05:21 PM
New to Overclock.net
 
PhillyB's Avatar
 
Join Date: Sep 2014
Location: Kincheloe, MI
Posts: 491
Rep: 26 (Unique: 25)
This is not a good measurement of input lag.

Problems are:
- processing time that delays the output beep is unknown
- OS event for mouse may not be as the button is clicked, its when the OS gets to it, which will be variable
- process to produce beep, if software related may be delays as cpu processing is not continuous, its framed
- scripts are interpreted code (not compiled) so there is a delay by the interpreter
- the snap may not actually be the switch toggling to fire the click event
- are you sure that the program running is not at the normal 60hz refresh rate of a lot of applications? Essentially, did the mouse fire happen in a 16.7ms time frame and then the next frame is producing audio?

At best, the value you are getting is the variance in the timing for the os to produce a beep and click sound of a mouse. The irregularity of the times given lead to this conclusion. Basically, the difference in min/max time values of creating audio based on a click.
PhillyB is offline  
post #7 of 22 (permalink) Old 10-20-2019, 05:38 PM
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,721
Rep: 78 (Unique: 63)
Quote: Originally Posted by PhillyB View Post
This is not a good measurement of input lag.

Problems are:
- processing time that delays the output beep is unknown
- OS event for mouse may not be as the button is clicked, its when the OS gets to it, which will be variable
- process to produce beep, if software related may be delays as cpu processing is not continuous, its framed
- scripts are interpreted code (not compiled) so there is a delay by the interpreter
- the snap may not actually be the switch toggling to fire the click event
- are you sure that the program running is not at the normal 60hz refresh rate of a lot of applications? Essentially, did the mouse fire happen in a 16.7ms time frame and then the next frame is producing audio?

At best, the value you are getting is the variance in the timing for the os to produce a beep and click sound of a mouse. The irregularity of the times given lead to this conclusion. Basically, the difference in min/max time values of creating audio based on a click.
While it's true there are unknown sources of latency, if the sampling was 60hz, there should be at least 16.7ms difference between the slowest and the fastest sample. How many samples you need to reliably get that, I don't know.

As for the audible click vs electrical contact within the switch, that should be less than 2ms, because that's about how long it takes the contact to go from the top contact to the bottom contact for a normal click. Though you might be able to analyze the sound further to figure out if you're hearing the spring buckling or the contacts banging into each other.

TranquilTempest is offline  
post #8 of 22 (permalink) Old 10-20-2019, 05:51 PM - Thread Starter
New to Overclock.net
 
M1st's Avatar
 
Join Date: Jun 2015
Posts: 809
Rep: 35 (Unique: 27)
Quote: Originally Posted by TranquilTempest View Post
Though you might be able to analyze the sound further to figure out if you're hearing the spring buckling or the contacts banging into each other.
I listened to it at 0.01 speed, sounded like contact bang (distinct hit sound, is actually very short and happens in the middle of red blip).

Quote: Originally Posted by PhillyB View Post
At best, the value you are getting is the variance in the timing for the os to produce a beep and click sound of a mouse. The irregularity of the times given lead to this conclusion. Basically, the difference in min/max time values of creating audio based on a click.
Actually bigest part of the variance most likely comes from the fact that bounce duration of the switch itself is different depending on how it's clicked. Not like it debunks things you said, though. That's why minimum time is most interesting.
M1st is online now  
post #9 of 22 (permalink) Old 10-20-2019, 05:53 PM
New to Overclock.net
 
PhillyB's Avatar
 
Join Date: Sep 2014
Location: Kincheloe, MI
Posts: 491
Rep: 26 (Unique: 25)
Quote: Originally Posted by TranquilTempest View Post
While it's true there are unknown sources of latency, if the sampling was 60hz, there should be at least 16.7ms difference between the slowest and the fastest sample. How many samples you need to reliably get that, I don't know.

As for the audible click vs electrical contact within the switch, that should be less than 2ms, because that's about how long it takes the contact to go from the top contact to the bottom contact for a normal click. Though you might be able to analyze the sound further to figure out if you're hearing the spring buckling or the contacts banging into each other.
The huge variance in the recorded times is the primary problem with relying on the results for this program. If it was consistent, then it would be workable to eliminate the unknown latencies. But, the results are two problematic to do that.

To discover an actual latency problem like this, something much more refined is needed than a click in a microphone. Even the recording itself could be part of the problem. Too many variables for something that is measured in milliseconds.
PhillyB is offline  
post #10 of 22 (permalink) Old 10-20-2019, 06:35 PM
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,721
Rep: 78 (Unique: 63)
The sample rate is likely 22 or 44 khz, so there's probably more resolution to be had from this technique if you look at the recording in a different program.

As for variance in recorded times, it's entirely possible that most of it comes from the mouse's debouncing technique, and 1ms comes from the polling interval.

It's better to view this in combination with other measurement techniques, rather than by itself.

Here's a paper for a more direct measurement, using a raspberry pi: https://epub.uni-regensburg.de/40182...or_version.pdf

If some people with one of the devices tested in that research paper could run some tests using this technique, we can get a better idea of how accurate the method is.

TranquilTempest is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off