All About Emulator Performance, and Input Lag
Older video game consoles deal with just about everything (polling input, rendering pixels, keeping audio in sync..) differently versus how your modern PC (and modern display) do business nowadays. A nasty side effect of the desire for massive resolutions and ultra-fast framerates is the necessity to buffer/postprocess/funnel thru many layers of hardware and software - net effect is latency, or input lag.
So I'm clear, by "latency" I mean the duration between an event occurring (say, the user pressing a controller button) and the reaction to that event. This is the only thing that probably will not be solved completely, and because of the aforementioned differences with how the old systems (and their games) expect to work, might be the most disappointing thing about emulation.
But, like I said, as long as you are not blessed with some incredible perception to latency or are not a competitive player, you will probably not be able to tell a significant difference, given the right settings.
First, a
primer by byuu (author of higan) on the causes. Although he may make the situation sound incredibly grim, he is laser focused on complete and total accuracy - so his stance makes sense.
Things that do not work (or cons outweigh pros), in my opinion:
- Adjusting the USB polling interval
- Messing with DirectInput/XInput/other Input API layer settings
- WASAPI Exclusive Mode (Windows only)
You can give these things a shot, but I personally do not find incredible value in them. YMMV.
As to things that do work, let's start at the end of the pipeline:
TV or other display
If you are buying a display with any kind of gaming in mind - it's worth checking
DisplayLag's database. If your monitor has a "Game Mode" - try it. It may make a big difference. Some models have a specific input that is designed for lower latency. Double check.
Audio/AVR
If you are outputting audio and video over HDMI - and I think you should to help keep things in sync - you effectively bypass much of the on-board audio hardware and have very few options in software to postprocess the audio stream. For gaming, this is a good thing. AVR's can be configured to delay or advance the audio stream to adjust for lip sync, so check that setting as well.
OS
I am not as experienced on this topic on Linux as I am on Windows, but on Linux you're going to want a minimum of extras running, and a working DRM video driver. On Windows, sadly different versions of GPU drivers can affect latency in big ways - so I'm much more hesitant to upgrade drivers. For my build, I'm normally not running the Windows shell. I set the power profile to "Performance" so as to effectively disable CPU P-states, and I disable the Xbox DVR function. The former setting change is due to the fact that oftentimes only one CPU core is going to be significantly loaded, but we want that core to be clocked as fast as possible rather than have the OS trying to reduce clock speed.
Retroarch
Libretro and Retroarch actually try their best to reduce latency and keep things in sync (audio+video) rather than just syncing to the audio stream or to vsync. This is unique versus other emulators, so taking this into account alongside other nice features, I stick to Retroarch as much as possible. There is a combination of settings that is known to work well in Windows:
video_driver = "gl"
video_vsync = true
video_threaded = false
video_fullscreen = true
video_windowed_fullscreen = false
video_hard_sync = true
Particularly to keep video_threaded disabled and to keep the framerate high, we need a fast CPU.
There are slightly different recommendations for Linux and specifically the RPi - an
extensive study has occurred here across many configurations and sets of hardware. See
here for the results, recommendations, and further tuning you can do.
Other resources on this topic:
https://www.raspberrypi.org/forums/viewtopic.php?f=78&t=142251
http://filthypants.blogspot.com/2015/06/latency-testing.html