Particularly to keep video_threaded disabled and to keep the framerate high, we need a fast CPU. There is a combination of settings that is known to work well in Windows: This is unique versus other emulators, so taking this into account alongside other nice features, I stick to Retroarch as much as possible. 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. 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. I set the power profile to "Performance" so as to effectively disable CPU P-states, and I disable the Xbox DVR function. For my build, I'm normally not running the Windows shell. On Windows, sadly different versions of GPU drivers can affect latency in big ways - so I'm much more hesitant to upgrade drivers. 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. AVR's can be configured to delay or advance the audio stream to adjust for lip sync, so check that setting as well. 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. Some models have a specific input that is designed for lower latency. If your monitor has a "Game Mode" - try it. If you are buying a display with any kind of gaming in mind - it's worth checking DisplayLag's database.
YMMV.Īs to things that do work, let's start at the end of the pipeline: You can give these things a shot, but I personally do not find incredible value in them. Messing with DirectInput/XInput/other Input API layer settings.Things that do not work (or cons outweigh pros), in my opinion: Although he may make the situation sound incredibly grim, he is laser focused on complete and total accuracy - so his stance makes sense. 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.īut, 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.įirst, a primer by byuu (author of higan) on the causes. 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. 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. 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. Here's a great example of that.Īll About Emulator Performance, and Input Lag Depending on your exact gaming needs as well it may be worth it to opt for the GTX 1060, though that adds around $100 USD (and some additional power requirements) to the build.įor my purposes, the discrete GPU is there for increased capability and performance in filters/shaders, as well as when you get into graphics renderers in 5th gen console emulation and beyond, which will make direct use of the GPU. I'd say that is easy enough to fix by swapping in a Core i5-6600 (over the i3: 2 more cores, only 14W added TDP, 3.3GHz/3.9GHz turbo - $50 USD more or thereabouts). I have a few AMD APU-based machines (now over 3 years old) scattered across the house that serve as set-top boxes running Kodi and they just don't break a sweat.ĭepending on the complexity of your CAD drawings or models, I would be a little worried that the hardware would run out of steam. If you opted to connect this machine to two displays (maybe a monitor, and a TV), and have it boot to the regular Windows shell I think it would be fine to watch TV and surf or edit simultaneously. Kodi will start on boot and will be perfectly capable of playing 4K, h.265, Hi10P - you name it. As-is, this build is an incredibly capable media playback, web and document machine - though perhaps even a hair overpowered.