Android RetroArch audio and performance tuning / 2026-08-02

RetroArch dynamic rate control on Android: fix drift without hiding slow emulation

Use small audio-resampling corrections for close refresh-rate mismatches, and recognize when CPU, driver, or display timing is outside that job.

10 minute tuning guideCurrent RetroArch timing concepts; Android display modes, drivers, and exposed settings vary by device and distribution

RetroArch dynamic rate control on Android: fix drift without hiding slow emulation

Dynamic rate control gently adjusts the audio resampling ratio so audio and VSync can stay synchronized when emulated and displayed rates are already close. It cannot supply missing CPU time or repair a large refresh mismatch. Establish full emulation speed and stable VSync first, then change the maximum timing skew in small steps while observing crackle and frame pacing.

Do this in order

  1. 01

    Record Android device, display mode, RetroArch and core versions, video/audio drivers, VSync state, and the authorized test scene.

  2. 02

    Disable rewind, run-ahead, shaders, filters, and unrelated latency experiments, then confirm the core reports sustained full emulation speed.

  3. 03

    Observe the estimated display refresh rate over a stable interval and compare it with the content rate; do not copy a value from another screen or device.

  4. 04

    With VSync working, enable the build's dynamic rate control and start from its default or a very small documented maximum skew.

  5. 05

    Run the same scene long enough to expose drift, recording crackle, pitch instability, duplicate frames, and reported speed.

  6. 06

    If the gap is large or speed is below 100 percent, restore timing defaults and repair the performance, driver, or display-mode layer instead.

Decision and diagnostic table

ResultInterpretationNext move
Slow drift disappearsSmall clock mismatch correctedKeep the smallest stable setting
Crackle tracks speed below 100%CPU/core budgetReduce workload or choose a suitable core
Regular judder with full speedVSync/display mismatchVerify refresh mode and video driver
Pitch visibly wandersCorrection range too large or unstableRestore default and remeasure

Rate control is a synchronizer, not a speed hack

Libretro's method assumes the game and display rates are close. It changes audio resampling slightly to prevent the buffer from repeatedly blocking or starving while video follows VSync.

Measure the screen you are actually using

Android devices may change refresh mode with resolution, power state, or display policy. A stable estimate from the current mode is more useful than the panel's marketing number.

Keep one-variable evidence

Audio latency, run-ahead, shaders, frame delay, and rate control affect different pipeline stages. Reset unrelated experiments and change one control so a clean result remains reversible.

First-party sources

Related guides