Retroarch Input Lag Settings

[Lordmonkus]

A user by the name of Brunnis over on the Retroarch forums has done a lot of work testing and improving input lag. He started out testing to see why Snes always had higher levels of lag compared to other emulators and if it could be improved. He finally posted a write up on settings to use to reduce it as much as you can in Retroarch itself, here is the forum post for it. Start at the beginning of the thread which is quite long and technical if you want to know more.

http://libretro.com/forums/showthread.php?t=5428&page=36&p=49145&viewfull=1#post49145

Here is the copy and paste of the post he made.
All of this information is from Brunnis and he gets all the credit for it, I am simply pasting it here.

Linux

Important: Run RetroArch from an X-less terminal. This requires a working DRM video driver, which most modern systems appear to have. See https://github.com/libretro/RetroArch/wiki/KMS-mode

Important #2: You may get performance issues unless you set your CPU to max frequency. This is because the CPU's power management thinks the CPU is idle enough to be downclocked. In Ubuntu, you can run sudo cpufreq-set -g performance to do this. You may want to put this in a startup script.

In retroarch.cfg set:

video_driver = "gl"
video_vsync = true
video_threaded = false
video_max_swapchain_images = 2
video_frame_delay = See description further down


Windows

In retroarch.cfg set:

video_driver = "gl"
video_vsync = true
video_threaded = false
video_fullscreen = true
video_windowed_fullscreen = false
video_hard_sync = true
video_frame_delay = See description further down


Note on video_max_swapchain_images setting

When using the OpenGL ("gl") video driver, this setting switches between using two or three buffers for rendering. Without going into details, a setting of 3 allows the emulator to run ahead and prepare the next frame before the current one has even been shown. This improves performance (i.e. makes framerate hiccups less likely), especially on slow hardware, but increases input lag by one whole frame in the general case.

So, the general rule is to use a setting of 2 if the system can handle it. It will shave off one frame of input lag compared to the default setting of 3. Please also note that a setting of 2 forces vsync on.


Note on video_frame_delay setting

This setting delays the running of the emulator by the specified number of milliseconds. This sounds bad, but actually improves input lag, since it pushes the input polling and rendering closer to when the frame will actually be displayed. For example, setting video_frame_delay = 10 shaves off 10 ms of input lag.

The general rule here is to use the highest value possible that doesn't cause framerate or audio issues. This is highly system dependent. The faster your system is and the less demanding the emulator is, the higher you can push this setting. On my Core i7-6700K, I can put this setting at 12-13 ms when using snes9x2010, but not nearly as high when using bsnes-mercury-balanced.

Please note that the frame delay value can't be higher than a frame period (which is 16.67 ms at 60 Hz). I believe the GUI caps this setting to a maximum value of 15.

I would also advice to play with this setting last. It takes a bit of trial and error to find a good setting, and unless you're willing to make per game settings, you might not be able to find a setting that works well in all situations while still giving a worthwile improvement.


A general note on GPU drivers

Input lag can vary depending on GPU driver, so it's not possible to guarantee a certain input lag without testing the particular combination of hardware and GPU driver. For example, I have measured different input lag when just upgrading from one GPU driver version to another. Currently, my safest bet for low input lag would be to use Linux in KMS/DRM mode with the above mentioned settings.


Note on Raspberry Pi

The Raspberry Pi is sort of a special case. In general, it's too slow to use anything other than the default value for video_frame_delay (which is 0). Also, unless you're using the experimental open source OpenGL driver, the video_max_swapchain_images setting has no effect.

In retroarch.cfg set:

video_driver = "dispmanx" ("gl" if you require 3D acceleration or shaders. Will add one frame of input lag compared to dispmanx driver.)
video_vsync = true
video_threaded = false
video_frame_delay = 0

The settings above are what's recommended for all of those using the default Raspberry Pi GPU driver. I have some comments coming up regarding the experimental OpenGL driver.


Regarding accuracy vs input lag

There's no real correlation between the two, except that accuracy usually comes with a performance penalty (i.e. frame rendering times increase). This, in turn, makes it less likely that you can use video_max_swapchain_images = 2 and high video_frame_delay numbers. I'd choose the emulator(s) I prefer/need for the games I play and then tweak the above mentioned settings to their optimal values.

 

UPDATE:

Version 1.6.0 of Retroarch added in a new input driver, RawInput which reduces input latency even further. This setting is in the Settings > Driver > Input Driver, set this to Raw,