You press jump, the character sets off a moment later, and the game you knew by heart becomes unplayable. Input lag is the delay between pressing the button and the movement on screen. It never comes from a single cause: it's the sum of small delays, between the controller, the system, the emulator and the screen. Nobody brings it down to zero, original hardware included. Two or three settings, on the other hand, remove whole frames, and make the difference between "mushy" and "fine". The rest belongs to forum legend.
What you're actually measuring
Input lag is the total time between the action and the pixel that changes. At 60 frames per second, one frame lasts 16.7 ms: that's the useful unit of account, and gains are reasoned in frames.
First point: the original game was already behind you. Most titles read the controller, calculate, then display the result one or more frames later. To count this internal delay, the RetroArch documentation gives a method: pause the game, hold a direction, and advance frame by frame until the character moves; the number of advances minus one gives the frames belonging to the game itself. That figure caps the gains available. RetroArch also claims a response on the next frame, meaning 16 ms or less, when the chain is properly set up.
The threshold at which it becomes annoying depends on the game and on habit: tolerance isn't the same in turn-based play, in pixel-perfect platforming and in fighting games.
The chain, link by link
| Link | What happens there | Room for manoeuvre |
|---|---|---|
| Controller | Reading the buttons, wired or radio transmission | Low, except with poor wireless |
| System | Input driver, Android or Linux layer | Medium, via the firmware |
| Emulator | Reading inputs, video and audio buffers, run-ahead | High: everything is won here |
| Game's internal delay | Frames the original game takes to react | None, except compensation via run-ahead |
| Screen | Panel processing and display | None on a handheld, the screen is soldered in |
The hierarchy is clear: the emulator first, the system next, the controller last. Many people do the opposite and change controller over a video buffer problem.
The settings that count, ranked by real gain
It all happens in RetroArch's Latency menu and in the audio and video settings, whose navigation is covered in our guide to the essential settings.
1. Run-ahead
The only setting capable of removing frames imposed by the original game. The emulator runs the logic one or more frames ahead, then reloads the earlier state, which brings your button press closer to the moment the game reads the input. Default value: 1 frame.
Three modes. Single instance runs ahead then reloads the current state. Second instance keeps a second core, video only, one frame into the future, which avoids the audio artefacts of state loading; this is the default mode. Preemptive frames replays past frames with the new input when needed, a variant the documentation presents as the most economical.
The cost is plain: the more frames you add, the higher the processor load climbs, since the logic runs several times per image, and second instance adds a core in memory. All of it requires save states: without them the feature is unavailable, and preemptive frames switch off for lack of deterministic saving.
A modest Linux console such as an Anbernic RG35XX Pro takes run-ahead on light systems, not on what is already running at the limit; a Retroid Pocket 5 has more headroom. Turn it on, check the speed, and come back down as soon as the sound hiccups.
2. The audio buffer
Often overlooked, it's the largest delay stated outright. RetroArch's default audio latency is 64 ms, with the driver aiming for half that value. On Android and Miyoo, the default rises to 128 ms, because 64 ms causes too many dropouts there.
Lowering this buffer brings the sound closer to the image, at the price of crackling. Go down in steps, and go back up at the first splutter. The setting has no effect on the buttons, but it changes the feel a great deal.
3. Vertical sync and frame buffers
Vertical sync removes tearing but means waiting for the screen refresh. On by default, it's the right choice; its neighbours matter more:
- Maximum number of queued frames: 3 by default, adjustable from 2 to 4. Going down to 2 shortens the queue, at the risk of stutter.
- Hard GPU sync: off by default, 0 frames ahead when you turn it on. It reduces the delay and costs performance.
- Frame delay: 0 by default, up to 99 ms. It postpones the calculation after the refresh, so the input is read later and is therefore fresher. Set too high, it drops frames; the automatic mode starts from three quarters of a frame's duration.
- Scanline sync: reduces the delay, but requires turning vertical sync off and increases the risk of tearing.
On a handheld, start with automatic frame delay: the best gain-to-risk ratio.
4. Controller polling
RetroArch's polling behaviour decides whether inputs are read early, normally or late in the frame: the default is already "late", the most favourable, so there's nothing to gain. That leaves the controller's electronic polling rate: at 125 Hz it transmits every 8 ms, at 1,000 Hz every 1 ms. Set against a frame of 16.7 ms, the difference carries little weight. The last link to optimise.
Wireless versus wired: less clear-cut than people say
The Gamepadla test database, which compares controllers over wired, 2.4 GHz dongle and Bluetooth connections, shows smaller differences than expected. A DualSense is recorded there at 7.81 ms wired, 6.56 ms on a dongle and 9.03 ms over Bluetooth; a GameSir Tarantula 8K at 1.04 ms wired, against around 3.5 ms on a dongle as well as over Bluetooth.
Wired remains the most consistent, a good 2.4 GHz dongle comes close, and Bluetooth adds a few milliseconds without being a disaster. Its weakness is sensitivity to interference: it's the inconsistency, more than the average, that spoils the feel. On a handheld, the question only arises when plugged into a TV or with an external controller: see the retro controllers section.
What makes no difference, whatever you read
- A faster microSD card. It changes loading times, not latency.
- Overclocking, if the game already runs at full speed. It only serves to fund run-ahead or make up for dropped frames.
- A 1,000 Hz controller facing an emulator at 60 frames per second. The gain is measured in fractions of a frame.
- Stacking up "anti-lag" options. Some contradict each other: the documentation advises against combining black frame insertion with frame delay.
- Changing firmware for latency alone. A custom firmware mainly brings usability and up-to-date cores, as our comparison of alternative firmwares explains.
Measuring it yourself, without lab equipment
Film your thumb and the screen in the same frame, at 240 frames per second, then count the frames between the press and the first movement: one frame is worth 4.17 ms. Do five runs and take the average; the measurement is noisy but the trend is reliable. Follow it up by counting the internal delay, which gives the run-ahead ceiling.
Test one setting at a time, on the same passage, blind if possible: this is the area where people believe they feel gains that don't exist. If the game then stutters, our article on the causes of crashes and slowdowns sets out the approach.
Fighting games and rhythm games
In a fighting game, everything comes down to the frame. Run-ahead set just below the game's internal delay is the only measure that changes things, along with a wired connection or the built-in controls. Don't expect the feel of an arcade cabinet: the modern display chain isn't that of a cathode-ray tube.
In a rhythm game, the problem isn't the button but the gap between sound and image: the default audio buffer is enough to shift the feel. Lower it as far as the hardware allows, then use the game's internal calibration.
Does run-ahead work on every retro handheld console?
No. It requires a core that handles save states and some power in reserve, since the logic runs several times per image. On modest Linux machines, it works on light systems, never on what is already saturated.
How many frames of run-ahead should I set?
Never more than the game's internal delay, measured by advancing frame by frame: beyond that, stutter and rewinds. The default value of 1 frame remains the right starting point.
Should I turn vertical sync off to gain responsiveness?
It isn't the first lever: turning it off exposes you to tearing for a limited gain. Scanline sync, which requires disabling it, reduces the delay but increases that risk. Prefer frame delay.
Does a Bluetooth controller make a game unplayable?
No, in most cases: public measurements put it a few milliseconds behind wired, not a whole frame. Its weakness is inconsistency in a crowded radio environment. For fighting games, stay wired.
Why does the sound seem to lag behind the image?
Because the audio buffer is sized to avoid dropouts, not for responsiveness: 64 ms by default, 128 ms on Android and Miyoo, with the driver aiming for half that value. Go down in steps, and stop at the first crackle.
To compare models by their real power, and therefore their suitability for run-ahead, go through the comparison tool, then the handheld consoles section.