Use MAME low-latency mode on Android without creating frame jitter
Use MAME's `lowlatency` option only after an Android port proves it exposes the upstream setting and the game already sustains full speed. The option draws a new frame before throttling and is especially useful with variable-refresh displays, but MAME leaves it off by default because some systems can show frame-pacing jitter. Compare the same input and scene with the option off and on; revert if pacing or audio worsens.
Do this in order
- 01
Record the Android port, upstream MAME revision, renderer, display refresh behavior, input method, machine short name, and a full-speed baseline with low latency off.
- 02
Confirm in the port's own UI, help, configuration output, or launch log that it exposes upstream `lowlatency`; do not infer support from the product name.
- 03
Use one authorized game and one repeatable response, then record speed percentage, visible pacing, audio stability, and input response after the device is warm.
- 04
Enable only low latency, restart if the wrapper requires it, and repeat the identical scene without changing VSync, frameskip, throttle, speed, renderer, or audio buffer.
- 05
Keep the setting only if response improves while full speed, pacing, and audio remain stable; revert it if jitter, judder, crackle, or slowdown appears.
- 06
Save the result at the narrowest supported scope and retain the off/on receipt because another machine, core revision, renderer, or display may need a different decision.
Decision and diagnostic table
| Setting or symptom | What it changes | Decision boundary |
|---|---|---|
| `lowlatency` | Draws a frame before throttling | Can reduce latency; may add pacing jitter |
| Run-ahead | Executes and restores serialized states | Different technique with state and CPU requirements |
| VSync / waitvsync | Coordinates presentation with display refresh | Can affect tearing and blocking; not the same switch |
| Below 100% speed | Emulation cannot meet real-time demand | Restore performance before latency tuning |
Low latency changes scheduling, not game logic
MAME documents the option as drawing a new frame before it throttles. That is different from RetroArch run-ahead, which relies on serialized states to advance and roll back internal game execution.
VRR is a strong fit, not a guarantee
MAME calls the option particularly effective with variable refresh rate displays, but also warns about jitter on some systems, especially newer 3D machines or systems running operating-system-like software. Android adds its own compositor, renderer, and wrapper boundary.
Performance is the control condition
A slower-than-real-time machine already misses its timing budget. First restore a clean full-speed baseline, then change only low latency. A subjective result without the speed and pacing observations cannot separate faster response from unstable output.
Latency tuning changes emulator presentation only. Use an authorized test game, do not attach ROMs or BIOS files to results, and do not treat a working configuration as permission to copy or distribute game data.