Set RetroArch run-ahead for Android arcade cores without stutter
First prove that the core runs at full speed with stable audio and default latency settings. Measure the game's internal response with pause and frame advance, then set no more run-ahead frames than the measured internal lag minus the next visible frame. Run-ahead depends on fast, reliable save states and extra CPU work; if input causes rollback artifacts, buzzing, crackle, or speed loss, reduce it or disable it. For current libretro MAME, Libretro describes support as partial and recommends second-instance run-ahead where available.
Do this in order
- 01
Use one authorized game, disable run-ahead and pre-emptive frames, remove shaders, and confirm sustained full speed, clean audio, stable controls, and a working ordinary save/load state.
- 02
Pause on a repeatable scene, hold a direction or button, advance one frame at a time, and count advances until the first visible response; repeat several times and record the shortest stable result.
- 03
Set run-ahead to the measured internal-lag amount, starting at one frame, and choose second-instance mode only when the core/build exposes it and the device has enough memory and CPU headroom.
- 04
Repeat the same input test while watching speed, frame pacing, audio, and rollback artifacts; if behavior jumps or stutters on input, the frame count is too high or serialization is unsuitable.
- 05
Compare with run-ahead off and change no other latency or video feature during the test; threaded video, hard sync, frame delay, shaders, Bluetooth, and display processing belong to separate layers.
- 06
Save the result as a game-specific override, keep an off baseline, and retest after any RetroArch, core, Android, or device-firmware update.
Decision and diagnostic table
| Observed result | Meaning | Decision |
|---|---|---|
| Action appears after several frame advances | Measurable internal game lag | Test one run-ahead frame at a time |
| Save/load state is broken or slow | Serialization prerequisite failed | Leave run-ahead off |
| Stutter appears only when input changes | Too many frames or state side effect | Reduce frames or use supported second instance |
| Core falls below full speed or audio crackles | Insufficient performance headroom | Disable run-ahead before other tuning |
Measure internal lag instead of guessing
Libretro's run-ahead guide defines the target as lag inside the emulated game's own response. Frame advance gives a repeatable count; setting more frames than the game actually delays can create visible rollback or other incorrect behavior.
Controller transport, Android display composition, television processing, and video-driver queues add latency elsewhere. Run-ahead does not remove those layers, so a subjective button test alone cannot select a safe frame count.
Save-state quality and performance are hard gates
Single-instance run-ahead repeatedly saves, advances, displays, and reloads state in memory. Two-instance mode avoids some audio-state reload problems but runs another core instance and needs more resources.
A core without clean, fast serialization is not a candidate. An Android device already below target speed will usually become less stable because every run-ahead frame adds emulation work.
Arcade core support is version-specific
Libretro's current arcade guide says FinalBurn Neo fully supports run-ahead and pre-emptive frames, while current MAME support is partial and second-instance run-ahead is recommended. Frozen MAME-family cores can differ again.
Record the exact core name and revision rather than copying a global recommendation. Keep the adjustment at game scope so one compatible title does not impose a costly or unstable setting on every arcade core.
Latency tuning changes execution, not content rights. Measure only a game you dumped lawfully or obtained from an explicitly authorized source, and do not bundle ROM, BIOS, CHD, artwork, music, or proprietary controller software with a configuration profile.