An input lag investigation


So what I picked up so far is that emulation vs real hardware + CRT is about 1 frame difference, is this accurate?

Also, is snes9x2010 still the best/low input lag core for snes? Should we use 2010 or 1.57 version that was released a few days ago if input lag is our main concern?


it’s far more nuanced than this but for emulators that work in slices of full frames (*and with vsync on the host), which is the most common type and the kind retroarch was designed to handle, that is more or less accurate. also, this assumes your gpu driver and hardware aren’t buffering frames outside of the emulator’s control and there exists a way to initiate the gpu into drawing the just submitted draw commands immediately (eg using video_hard_sync in retroarch when using the opengl driver). also, this doesn’t necessarily apply when emulating 3d systems where the graphics are handled via translating draw commands from the guest into equivalent ones on the host.

runahead can be used to mitigate this last single frame difference, and even surpass it in instances where the game is natively buffering inputs (like Super Mario World, for instance).

snes9x2010_libretro and snes9x_libretro should be identical in latency, provided your machine is fast enough to handle the latter.

*EDIT: forgot to mention this assumes vsync on the host, with vsync off and with conventional emulator design (ie not beam racing) it can be less than a frame difference, but then you’ll also have screen tearing.


To add to what e-tank wrote:

By using a fast desktop computer and low latency (1000 Hz) USB controllers, I’ve gotten down to just ~5 ms (0.3 frames) average extra input lag compared to a real NES or SNES on a CRT. Regular USB (125 Hz) controllers will add a few ms to that, but still only ~0.5 frames of extra lag compared to the real consoles. To get input lag this low requires you to use the Frame Delay setting to eek out the last input lag reduction. Without using Frame Delay, ~1.0-1.2 frames is probably a good ballpark figure.

The above is without using run-ahead, by the way.


holy crap that’s insane. and you’re using the newest SNES core too? thanks for the follow up man. great info.

what frame delay do you use? I tried 15 but it was way too much for my 7700k. settled on 12 but some games need to be dropped to 10 after setting up Runahead.

my buffalo USB snes controller seems to have the same Low and 0x0A interval, but PS4 controller connected via usb cable says Full and 0x05, which i think should actually be half the buffalo, 4ms. the buffalo experiences ghosting tho and I think PS4 one seems a bit laggy, maybe its DS4Windows. im getting an 8bitdo controller that I plan to use via usb, any ideas on the polling rate on that when connected via USB?

oh and one last thing, do you bother with Audio Latency or just leave it at the default 64ms?


I use snes9x2010 since it executes slightly faster, which allows for a (slightly) higher frame delay setting. I haven’t really had any issues with snes9x2010, otherwise I would just switch to snes9x. There’s no difference in input lag with the cores themselves.

I believe I got a frame delay of 13 or 14 to work on my 6700K @ 4.4GHz. The trick is to disable the power management of your Nvidia GPU. I have a GTX 1080 and disabling the power management in the Nvidia settings bought me ~2 ms extra on the frame delay.

Yeah, I also have a few of those Buffalo controllers. Most of them seem to have the ghosting issue and I actually devised a way of more or less fixing them. It requires soldering a few capacitors though. The good news is that the latency in the controller is otherwise actually really good. There’s no additional latency other than that caused by the standard 125Hz USB polling, so 4 ms average and 8 ms max.

I think 8bitdo uses 125Hz polling as well. 125Hz is really quite okay and I probably wouldn’t spend a lot of money just to get something with faster polling rate. I do use the SNES Classic Mini controllers with expensive adapters, but I did that mostly for the quality controller and not for the improved latency.

Please note that some controllers have internal latency not related to USB and those are important to avoid. The Retro-Link SNES replica I used for my initial input lag tests has this kind of lag, probably caused by some internal button polling loop not related to the external USB polling.

I haven’t played around much with audio latency, but I believe I use 48 ms on my current RetroArch installations. I’m not nearly as sensitive to audio latency as I am with video latency, though.


Sorry, forgot to answer your post (which you’ve now deleted?). I just checked my 8bitdo SFC30 (wired) and Buffalo controllers in USBView. The Buffalo has an 8 ms polling period. The 8bitdo has a 32 ms period, just as you also report.

It’s worth mentioning that the average latency will be half of this, so 4 ms for the Buffalo and 16 ms for the 8bitdo. I’d say it’s pretty unacceptable for a wired controller to cause 1 frame of input lag on average by itself. There’s really no reason for that.

Regarding the fact that there is two USB endpoint descriptors for the 8bitdo: I believe it’s the IN descriptor you should look at. The Buffalo only has the IN descriptor.

So, I guess the takeaway is that you should avoid using USB for the 8bitdo. Bluetooth will have around 8 ms extra input lag over a standard USB controller like the Buffalo, so around 12 ms average total input lag.


So, I guess the takeaway is that you should avoid using USB for the 8bitdo. Bluetooth will have around 8 ms extra input lag over a standard USB controller like the Buffalo, so around 12 ms average total input lag.

So, in general, will using a standard wired USB controller result in less latency than using bluetooth? Intuitively, it seems like that should be the case. Or is this one of those system-dependent things?


To be honest, I don’t know. I have only tested the 8bitdo SFC30 myself. However, I believe the DualShock 4 has lower latency over BT than wired. The DS4 doesn’t use 1000 Hz polling over USB, though, so I think USB could still be slightly faster in the optimal case.

If I were to guess, I’d say that an optimal BT connection should perform more or less the same as a USB connection. It’s of course dependent on how the BT receiver is connected to the system, though. If you have it hanging off of USB, you’ll obviously stack any delay from the BT communication with that of the USB connection…


Got a question anout beam racing and how it applies to my set up. I am using a pro crt monitor with crtemudriver to output 15khz.

As I understand it beam racing wouldn’t directly eliminate any input ag for me because I am using a crt but it could eliminate screen tearing and allow me to turn off v-sync, thereby indirectly reducing lag. Is this correct?


No that’s not correct. On a powerful enough pc, beamracing will eliminate (very close to) all input lag and deliver true hardware like response. It will work for both CRT or LCD. Relatively speaking it will even work better on CRT, as the hardware requirements will be much less compared to an LCD setup with resource intensive (CRT) shaders.

But don’t get your hopes up, because getting this implemented for Libretro cores is easier said than done. I guess the question for libretro is more an “if” than a “when”.


Rafan, thanks for clarifying. For now I’m really happy with run ahead.


So what are currently the best overall settings for acceptable input lag across all cores? I’ve been using vulkan because I was under the impression that it had similar input lag to opengl+hardsync, but without the performance impact. However, according to this thread, it seems to maybe be worse depending on the driver? Is that an AMD issue or does it affect Nvidia as well?

I suppose I could have a separate install of retroarch with opengl+hardsync for older systems, but then what would be the best configuration for more hardware intensive cores that don’t perform well with hardsync?

I’m currently on Windows 10 because I don’t feel like rebooting into Linux just to get lower input lag if that’s still a thing. I’ve used KMS in the past and never really noticed much difference in input lag. Plus, doesn’t nvidia not support any of that stuff?


It depends on how resource intensive the core is and game you’re playing.

For me I have an i5 4670k not oc’ed and GTX 770 and spent a good day off going through all the cores I use and obtained a general idea of what my machine can and can’t handle.

Using the OGL backend For example systems up until say PSX my machine can handle GPU hard sync 0, frame delay of 10 and run ahead of 2 frames (could handle even more frames but then the game starts to glitch) Using Game mode on my Plasma and DS4 Bluetooth connnection (4ms polling rate) I can’t tell the difference between my CRT and my Plasma with input lag. After PSX I cannot handle run ahead that well but I can get away with shaving off some lag with frame delay.


But what about vulkan vs opengl for hardware intensive cores?


I’ve never felt compelled to Use Vulkan because OGL has done the job for me so there I can’t really help you.


Some cores can’t be helped with whatever options you can throw at them. Mednafen Saturn and the more recent PPSSPP updates are the worst offenders. Same with some N64 games that use framebuffer. That’s more than 4 full frames of lag on top of any other lag from the LCD, etc. GPU sync, frame delay, etc barely do anything.


could you test the other input methods for the 8bitdo sfc30? I was under the impression that the xbox mode (x then turn on)of the control was faster than the d-input (turn on without pressing any extra button) one when conected over cable.


doesn’t mednafen saturn have have midframe input sync option to reduce input lag?


Yeah but it makes no difference. At least on the core/my system.


You probably have the equivalent of that playing with the “frame delay” value.
But that’s still really stressful on the cpu anyway.