An input lag investigation

RetroArch General
#793

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.

1 Like
#795

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.

2 Likes
#796

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?

#797

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…

1 Like
#798

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?

#799

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”.

1 Like
#800

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

#801

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?

#802

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.

#803

But what about vulkan vs opengl for hardware intensive cores?

1 Like
#804

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

#805

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.

1 Like
#806

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.

#807

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

#808

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

#809

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

#810

Does enabling rewind increase the input lag?

#811

Enabling rewind adds a savestate to every frame, which increases processing time by a very small amount. Saving state is usually far less work than emulating a frame.

It’s so insignificant that it only matters for people who are using the Frame Delay feature, and might need to turn that down a notch.

#812

Processing time as in additional input lag or additional cpu usage? I’m aware that it increases the cpu requirements for a core but didn’t know if it increased input latency.

#813

Rewind does have a significant performance hit though. It may depend on how the savestate code is implemented in each core I guess.