Android MAME refresh-rate performance guide / 2026-08-04

Use MAME refreshspeed on Android without hiding real slowdown

Decide whether a small display-refresh mismatch justifies a bounded emulation-speed adjustment, and separate it from throttle, frameskip, low latency, and CPU shortage.

9 minute performance decision guideOfficial MAME 0.289 refreshspeed behavior; Android display modes, compositor timing, and option exposure are port- and device-specific

Use MAME refreshspeed on Android without hiding real slowdown

Use `refreshspeed` only when the Android port exposes upstream MAME behavior, the machine already reaches full speed, and the target display is slightly slower than the emulated screen. MAME may reduce emulation speed so the first emulated screen does not exceed the slowest target monitor; that can avoid sound hiccups, but it intentionally changes speed. Do not use it to disguise major CPU or GPU slowdown.

Do this in order

  1. 01

    Record the Android port and upstream revision, machine short name, reported emulation speed, emulated refresh, selected Android display mode, renderer, and audio result with defaults.

  2. 02

    Confirm that the port exposes upstream `refreshspeed` and that the machine already holds full speed after the device is warm.

  3. 03

    Prove the mismatch is small and repeatable; if the machine is materially below full speed, follow the CPU, renderer, or thermal branch instead.

  4. 04

    Enable only refreshspeed, keep throttle on and speed at 1.0, then repeat the same scene without changing frameskip, lowlatency, VSync, renderer, or audio latency.

  5. 05

    Compare reported speed, sound continuity, pacing, and input response; accept the setting only if the deliberate slowdown is understood and the result is more stable.

  6. 06

    Save the choice for the narrowest machine or display scope and retest whenever the port, renderer, display mode, or Android version changes.

Decision and diagnostic table

ObservationMeaningDecision
60.6 Hz machine on 60 Hz targetSmall target mismatchrefreshspeed may trade about 1% speed for continuity
Machine already at 80%Insufficient performanceDo not mask it with refreshspeed
Speed stable, audio still cracksAudio or output pathDiagnose buffer and Android route separately
Input feels later after changeScheduling trade-offCompare lowlatency and pacing as separate decisions

refreshspeed changes the emulated clock

MAME documents a bounded speed reduction when the first emulated screen would outrun the slowest target display. This is not frame skipping and not a free synchronization fix; game and audio timing follow the changed emulation speed.

Full speed is the admission test

A device that cannot emulate the machine in real time has a performance deficit, not a small refresh mismatch. Restore defaults, remove expensive video work, check thermals, and prove the speed baseline before considering refreshspeed.

Android can change the target after launch

Variable refresh, system display modes, external screens, and compositor decisions can change the effective target. Record the active display result and repeat the receipt after any platform or port update.

First-party sources

Related guides