Fix RetroArch audio crackling on Android without masking slowdown
Restore default synchronization, remove shaders and run-ahead, and watch emulation speed during the crackle. If speed falls below the core's target, reduce workload first; a larger audio buffer cannot create missing CPU time. If speed is stable, test the device speaker, a fixed display refresh rate, and one conservative audio-latency change while preserving a log and a reversible baseline.
Do this in order
- 01
Record RetroArch and core revisions, audio and video drivers, display refresh mode, output device, and the scene where crackling begins.
- 02
Restore default sync and audio settings, disable shaders and run-ahead, close recorders, and restart the same authorized content.
- 03
Watch emulation speed for several minutes; if it drops with the crackle, reduce core and video workload before touching buffer latency.
- 04
If speed remains stable, test the device speaker with Bluetooth and USB audio disconnected, then verify Android media volume and audio focus.
- 05
Use RetroArch's measured display refresh information or a fixed Android refresh mode, retest, and keep dynamic rate control enabled for the baseline.
- 06
Change audio latency once in a conservative direction, retest the same scene through warm-up, and save the setting only if the crackle improves without unacceptable lag.
Decision and diagnostic table
| Evidence | Most likely boundary | Next action |
|---|---|---|
| Crackle plus speed below target | Core workload, video cost, or thermal throttling | Remove effects and profile sustained speed |
| Stable speed; only Bluetooth crackles | Android route, codec, or radio scheduling | Test speaker, then reconnect one device |
| Stable speed; periodic video stutter too | Refresh/vsync synchronization | Measure refresh and restore dynamic rate control |
| Only a very low latency setting fails | Audio buffer underrun | Return to the last stable latency |
Audio is often the first visible performance alarm
An emulator must deliver audio at a steady rate while also advancing the emulated machine and presenting video. When the core cannot sustain target speed, the buffer drains and crackling can appear before the visual slowdown is obvious.
Measure the core's speed rather than rendered FPS. Frames can be skipped while machine timing stays correct, or frames can be displayed while emulation runs late.
Synchronization is a system, not a collection of speed switches
RetroArch's dynamic rate control coordinates small differences between content timing and the display. Disabling synchronization options together may move the symptom while introducing uneven motion, pitch drift, or more latency.
Return to defaults, identify the actual display refresh rate, and change one layer. Threaded video can recover driver overhead on some devices, but Libretro documents a smoothness and latency trade-off, so it is a fallback with recorded evidence.
Warm-device results matter on Android
Android devices can reduce CPU or GPU capacity under thermal stress. A clean first minute followed by crackling later points to a sustained-performance boundary, especially if speed falls at the same time.
Retest after warm-up with the same power mode, screen brightness, and background load. Do not report a universal latency value from one phone; keep the result tied to the exact device, route, core, and scene.
Use your own lawful dump, creator-authorized content, or an original test program. A popular commercial game is not required to diagnose audio timing, and an emulator setting does not change content rights.