OSLTT User Guide – Mouse & Keyboard Latency, Game Latency & More!

I want to preface this by saying that this project is still in its early stages. What you see here may change over time as I fix bugs, add new features and improve the tool. If you have any questions please do leave them in the comments, on the Github repo, ping me an email or even jump on our Discord – all of that will be linked in the description. If you don’t happen to have an open source latency testing tool but you want one, head to OSRTT.com and pick one up. Right, let’s get into the tool.

Physically you’ll find a few main ports and inputs. You’ve got the USB C port on the side, as well as the microphone jack. I’ve included a mic in the kit, but if for some reason you want to use your own you’ll need to make sure it’s a mic jack or TRS, not a combined headphone jack, or four pole, TRRS jack. On the top you’ll find the indicator LED, the 2 pin input, and a crosshair built into the case to help you more easily line up the sensor on the screen. On the top side you’ll find the orange button that you’ll use to trigger at least some of the tests – or in the case of the mouse and keyboard test mode, you’ll use that to end the test too. On the bottom you’ll find the light sensor and the 2.5mm Allen key screws that hold the unit together. Not that you’ll need to, but if you do want to look inside, you just remove those two and pull the case apart. 

When it comes to the 2 pin input, it’s really important I make this clear. When looking at it from the top, with the orange button facing away from you, the top pin is ground and the bottom is the one you supply a voltage to. If you bought the fly leads from me, the one with the white sticker is the signal wire, and the other is ground. In an ideal world you’d only supply 3.3V to the signal wire, although just in case I’ve isolated the microcontroller so you technically can supply up to 50V without the transistor blowing up. To be clear – please don’t – but if you do by accident, I’ve designed a bit of safety in just in case.

Right, that’s the hardware. To get it working, you’ll need to install the software. Head to the Github repo linked in the description, specifically to the releases tab and download the installer executable. It will install to C:\OSLTT, and once you open it for the first time it will ask you if it can do some additional installation – specifically the tools needed to detect and update the board. Hit yes, then it’ll ask to install two drivers, one from Arduino and one from Seeed. Once done, if it needs a firmware update it should ask you to do that too. Mine obviously doesn’t so onto the software itself. 

I’ve tried to keep everything front and centre, so there aren’t any hidden options. You’ve got preset modes at the top, these just change what is selected on the options at the bottom – so monitor testing uses the light sensor, button trigger and the DirectX code I wrote. The mouse and keyboard testing preset uses the microphone to trigger it and the click/keypress capture test source. If you want to tweak any of these settings you can always hit “Custom” and change to your heart’s content. There are a number of configurations that, while they might be useful, at the time of filming aren’t supported, so the options menu won’t let you pick something that outright won’t work. With time I hope to support plenty more, and if there are any specific configs you want please do let me know, ideally on Github so I can keep track of everything. 

Let’s talk through some of the tests. I’ll start with the one I’m sure most of you are interested in, which is the peripheral testing mode – that’s mice and keyboards for now. You’ll need the microphone connected to the device – and here’s the important bit. The mic needs to be right up to the device you’re testing. Right next to the left click button on a mouse, or next to the keyboard key you’re going to press. Select the mouse and keyboard mode, hit start test, then click in the box or type in the text box below. Make your clicks and keypresses nice and loud, like this. Do as many clicks as you want – the more you do the more accurate the final results will be. Once you’re done, click the orange button on the top of the device to end the test. Clicking “end test” will technically work too, but at the moment that will soft-lock the device and you’ll need to unplug and reconnect it. I’m working on that. You should then see the results viewer pop up with the data. What shows up here is subject to change – but in short you should see a graph with the click times average, min and max, and if you hit “switch to individual results” you’ll see the scatter plot with each individual data point. You can also save the charts as images, either with a transparent or white background.

Moving on to the monitor testing mode, this is exactly the same as the input latency testing mode on OSRTT, so all you need to do is use the strap to secure it to your monitor, then if you have multiple monitors make sure you select which monitor from the dropdown here, then start the test. Your screen will go black as it launches the DirectX program. You’ll see the FPS counter up at the top left – you’ll want to wait until that starts sitting stably at around 1000 FPS, then hit the button on the device. Your screen will flash for as many times as you’ve set in the software – by default that’s 100. Again once it’s done you’ll get the results view with all the data – this time it’ll include the USB polling delay, the render time, and the on display latency. The latter is basically the time it takes from the GPU sending the frame to the monitor starting to display it.

The audio latency test is pretty simple too. Stick the microphone in the ear cup of the headset you want to test – or in front of your speakers, whatever you’re testing – then make sure the volume is turned up as high as it’ll go. The louder the beep, the clearer the results will be. To start, hit the button on the device. By default this will run 30 times – although you can increase that up to 500 if you want to go that kind of mad. Once it’s complete it will pop up the results viewer with all the data for you.

If you want to test games, you can hit the game mode, hit start test, then fire up a game. In my case I’m going with CSGO. It needs a recent light level difference, so I like to stand by these metal signs and have it shoot at the signs which produces a much brighter flash than the pistol itself. If a game has NVIDIA’s Reflex marker, that will work great too. Again by default once you hit the button on the device it’ll auto-fire. I go with 20 shots here as that’s the size of the pistol magazine in CSGO. If you auto-fire it should automatically end the test, or you can turn auto click off and just press the button to single fire instead. 

Lastly there is the external mode. If you want to test something else entirely, you can use the light sensor and either the button or the 2 pin input to trigger it. It’ll still process the data the same, and if you’re doing something the software can’t process right now, it will still save all the raw data as a CSV file which you can manually graph in Excel and check through yourself.

Just so you know the format, the first column is the click time in microseconds, the second column is the frame time (if it was using the DirectX mode, otherwise it will read 0), the third column is the total time it took to capture all the data in microseconds, and the fourth column is the number of samples taken. You can use those two to work out how long there was between samples. For the light sensor data, that should be around 15.1 microseconds, or for the audio data that’s around 35 microseconds. 

If, for example, you wanted to run multiple auto-click tests in a game, you can manually combine the raw data results and open the results viewer and re-import the file. It will then re-process those files and give you a new set of averaged results. You can also import existing processed files to view them in the results viewer if you want.

I think that’s about it for now. If you have any questions feel free to leave them in the comments below, as on the Github repo, ping me an email, or even jump on our Discord and head to the OSRTT and OSLTT support channel. All of that is linked in the description – and of course if you don’t yet have an open source latency testing tool, but you want one, head to OSRTT.com and grab one. I hand built all the units myself and validate them before shipping.