Input Lag: How Emulation Run-Ahead Can Achieve Lower Latency Than Original Hardware

You play a shmup on original hardware through a RetroTINK-5X Pro into a 4K OLED. Your ship feels slightly behind your thumb. Swap to RetroArch on the same screen with run-ahead enabled and that delay vanishes. A properly configured emulation run-ahead setup can beat original hardware on total chain responsiveness. The mechanism is simple. RetroArch calculates what frame would appear two or three frames ahead, renders that future frame, and discards the intermediate ones. Your button press appears on screen in fewer milliseconds than the original console could manage through a modern flat panel. Every claim here is backed by Time Sleuth measurements and the testing methodology published on Shmups Forum.

How The Frame Pipeline Works

RetroArch's run-ahead feature exploits a weakness in the emulation pipeline. A software emulator typically runs one frame behind because it must capture input, simulate the console hardware for that frame, and push the result to your GPU. That process adds one frame of delay, about 16.67ms at 60Hz, on top of whatever your screen adds. Run-ahead works around this by simulating two frames per cycle: the current frame and a future frame. It sends only the future frame to your screen, discarding the intermediate one. The input you pressed is reflected in the frame you actually see, cancelling the emulator's buffer delay.

The Performance Cost

This comes with real costs. Each run-ahead frame doubles the CPU and GPU work per displayed frame. A game that runs at 60fps on the emulator requires the host system to compute 120 frames per second internally. If your GPU cannot sustain that load, the emulator stutters or drops frames, which defeats the purpose. The Shmups Forum testing methodology measures this with Time Sleuth: a system that drops from 60fps to 55fps during run-ahead has already lost the advantage because the skipped frames introduce uneven timing.

Audio And Visual Trade Offs

The second cost is audio. RetroArch's audio latency compensation expects frames to arrive at a steady rate. When run-ahead forces the emulator to skip frames, the audio buffer starves. The result is crackle, pops, or outright silence. This is not a bug: it is the physical consequence of asking the emulator to produce more frames than the audio pipeline can consume. Lowering the run-ahead count or disabling audio sync in RetroArch's settings can help, but that trades audio quality for reduced lag.

Visual glitches are the third cost. Some games rely on frame-to-frame state for sprite flickering, transparency effects, or palette swaps. Run-ahead discards the intermediate frame that carries that state transition. A game that uses flicker to fake transparency, common in early 16-bit titles, may show solid instead of translucent objects. The 240p test suite includes a lag test pattern that reveals these artifacts: run it with run-ahead at two frames and watch for sprite breakup on the scrolling test.

The CRT Baseline

Original hardware on a CRT adds zero screen delay. The beam draws in real time. That is the baseline: 0ms added by the screen, plus whatever the console's own polling adds. For a SNES on a PVM-20L5, total input lag is roughly 2ms to 4ms depending on the controller and the specific game's polling window. A RetroTINK-5X Pro in line doubled mode adds less than 1ms. Total chain: under 5ms.

Where Flat Panels Fall Behind

Swap the CRT for a modern OLED. That same SNES through a RetroTINK-5X Pro into an LG C-series with Game Mode on adds 9ms to 15ms of screen processing, depending on resolution. The total chain jumps to 12ms to 20ms. That is the gap that software emulation with run-ahead can close.

RetroArch on a powerful PC, with run-ahead set to two frames, subtracts roughly 33ms from the emulator's own buffer. The emulator still adds its own base lag, 8ms to 16ms depending on GPU processing and USB controller polling. With two frame run-ahead, the total emulator contribution becomes negative relative to the screen: the emulator is sending frames that are ahead of the controller input in real time. On a 15ms screen, the total chain can drop below 10ms. That beats the original console on a flat panel by a measurable margin. Time Sleuth tests published on Shmups Forum confirm this: a RetroArch setup with run-ahead at two frames and hard GPU sync disabled can achieve 8ms to 10ms total lag on a 2023 OLED. The original console through a RetroTINK-5X Pro on the same screen measures 14ms to 18ms.

The catch: this works only if your hardware can sustain the doubled frame rate. A PC that cannot maintain 120fps internal will drop frames, and the run-ahead advantage vanishes. The failure case is a system that stutters at the moment you need low lag most, during heavy sprite count in a shmup or rapid scene changes in a platformer.

Configuration	Scaler/Emulator Lag	Display Lag (OLED, Game Mode)	Total Estimated Lag
SNES + CRT	0ms (CRT adds none)	0ms	2–4ms
SNES + RetroTINK-5X + OLED	<1ms (line double)	9–15ms	10–18ms
RetroArch, no run-ahead, OLED	8–16ms (emulator buffer)	9–15ms	17–31ms
RetroArch, run-ahead 2 frames, OLED	−33ms (net after subtraction)	9–15ms	8–12ms
MiSTer FPGA + RetroTINK-5X + OLED	<1ms (line double)	9–15ms	10–16ms

The answer depends on your emulator's base lag and your screen's processing delay. Measure both before configuring.

Measure Your Base Lag

Run the 240p test suite's lag test on your emulator. This test outputs a flashing pattern that a Time Sleuth or Leo Bodnar tester can read. Record the total chain lag without run-ahead. Subtract your screen's known delay, which you can find on RTINGS.com or measure with a Time Sleuth directly. The remainder is your emulator's base buffer lag. For RetroArch on a modern PC with Vulkan and hard GPU sync off, this is 8ms to 12ms. On a Raspberry Pi 4, it can exceed 30ms.

Calculate The Frame Count

One frame of run-ahead subtracts 16.67ms at 60Hz. Two frames subtract 33.33ms. Your goal is to set a count that brings the emulator's contribution to zero or slightly negative, but never so high that the internal frame rate drops. If your emulator's base lag is 10ms, one frame of run-ahead is enough. If it is 25ms, you need two frames. If it is 40ms, you need three, but three frame run-ahead requires the GPU to render 240 frames per second internally. Most systems cannot sustain that without stutter. At that point, the practical answer is to switch to a MiSTer FPGA or original hardware instead of chasing run-ahead.

Test With Your Most Demanding Game

Configure run-ahead per core in RetroArch. Set the frame count for the heaviest game you play, not the lightest. A game that runs at 60fps internally but has heavy sprite rendering, like a late stage in a Cave shmup, will stress the GPU more than a menu screen. If the game stutters at your chosen frame count, drop it by one and accept the remaining lag. The alternative, audio crackle and frame drops, is worse than a few extra milliseconds of delay.

The Audio Trade Off

RetroArch's audio latency compensation expects a steady frame rate. Run-ahead that skips frames starves the audio buffer. If you hear crackle, reduce the run-ahead count or enable audio sync in RetroArch's settings, which adds a small buffer but eliminates the pops. Some users disable audio entirely for lag-critical games and rely on a separate audio source. That is extreme but valid for competitive play.

Why The FPGA Needs No Run-Ahead

MiSTer FPGA does not need run-ahead. It does not buffer frames. The FPGA core is a logic level replica of the original console's silicon. Input from a SNAC adapter reaches the core with zero added polling delay, because the SNAC connects the controller directly to the FPGA's GPIO pins with no USB stack in between. The video output is cycle-accurate timing: the core generates the same signal timing as the original console, scanline by scanline. Through a RetroTINK-5X Pro in line doubled mode, total added delay from the FPGA to the scaler output is under 1ms. The screen still adds its own processing, 9ms to 15ms on an OLED, but the FPGA itself contributes nothing measurable.

Deterministic Vs Variable Lag

Compare that to a run-ahead emulation setup. The software emulator must approximate the console's behaviour on a general purpose CPU. Even with run-ahead, the emulator is guessing what the next frame will look like. The FPGA does not guess. It produces the correct frame at the correct time because it is built from logic gates configured to match the original hardware. There is no frame buffer, no GPU processing lag, no USB controller polling delay. The total chain lag is deterministic: you can predict it within microseconds because the hardware timing is fixed.

This matters for games where timing is absolute. A rhythm game like Dance Dance Revolution or a shmup like DoDonPachi requires consistent responsiveness, not just low lag. Run-ahead emulation can achieve lower peak lag than the FPGA, as shown in the table above, but the emulator's lag varies with GPU load, USB polling jitter, and background system processes. The FPGA's lag does not vary. If you need the lowest possible lag on a flat panel and can tolerate per-game configuration and occasional visual glitches, run-ahead emulation on a powerful PC is the technical winner. If you need consistent, predictable, zero configuration lag, the MiSTer FPGA with a SNAC adapter and a RetroTINK-5X Pro is the better choice.

The Cost Of The FPGA Path

The failure case for the FPGA is cost and availability. A DE10 Nano board, plus the required RAM and IO boards, costs more than a used PC capable of run-ahead emulation. In Hong Kong, sourcing a DE10 Nano at a reasonable price requires checking Golden Computer Centre stock or ordering from overseas distributors with shipping lead times. The MiSTer also requires a separate scaler for flat panel output, adding the cost of a RetroTINK-5X Pro or OSSC Pro. The emulation path uses hardware you may already own.