Nothing breaks the spell of a retro game faster than sound that lags the action. You press jump, the character leaves the ground, and the boing arrives a beat late like a badly dubbed film. On a RetroPie build that delay comes from a stack of buffers: the emulator core holds audio, the audio driver holds audio, and the Linux sound layer holds audio, each adding its slice of time. The good news is that every one of those slices is configurable, and on modest single-board hardware you can usually get latency down to the point where it disappears into the feel of the game. This guide walks the stack from the emulator settings down to the system audio layer.
Start with the emulator's audio latency setting
RetroArch, the frontend behind most RetroPie emulators, exposes an audio latency setting measured in milliseconds, and it is the highest-leverage knob you have. It controls how much audio the frontend buffers before handing it to the driver. The default leans safe, which on a Pi-class board can mean a very audible delay. Dropping it into the range of a few tens of milliseconds tightens sync dramatically on most cores. The tradeoff is the usual one: set it lower than the system can sustain and you get crackling instead of delay, which is arguably worse. Lower it in steps, play a game with constant sound effects for several minutes at each step, and stop at the lowest value that stays clean. Different cores behave differently, so a setting that is rock solid for an 8-bit core may crackle on a more demanding one.
Match the audio driver to the hardware
RetroArch offers several audio drivers, and the choice matters more on single-board computers than on desktops. The ALSA driver talks nearly directly to the kernel sound layer and generally gives the lowest achievable latency on these boards. Higher-level drivers that route through a sound server add their own buffering on top, which is convenient for desktop mixing but pure delay for a dedicated emulation box. Since a RetroPie build is usually a single-purpose machine, there is little reason to pay the sound-server tax. Switch the driver, restart the frontend, and re-measure by ear. If a particular core crackles under ALSA at latencies that were fine elsewhere, that core is telling you about its own internal buffering, which leads to the next knob.
Tune the audio rate control and resampling
Emulated systems did not run at exactly the sample rates modern hardware prefers, so the emulator resamples on the fly, and resampling needs a buffer. RetroArch's audio rate control settings manage how aggressively the frontend chases the correct rate. The maximum timing skew setting in particular controls how far the audio clock is allowed to drift before correction kicks in. A tighter skew means the resampler works with less lookahead, which trims latency but demands more consistent timing from the system. On a lightly loaded board this is free latency reduction. On a board that is also running background services or a heavy shader, it is a crackle generator. As with the latency setting itself, the right value is found empirically: tighten it until problems appear, then back off one step.
Reduce the system's own buffering
Below the emulator sits the system audio layer, and it has buffers of its own that no emulator setting can shrink. If the board runs a sound server, its fragment settings add tens of milliseconds before the emulator's audio even reaches the hardware. On a dedicated RetroPie build, bypassing the sound server entirely and letting the emulator talk straight to ALSA removes that whole layer of delay. Check what is actually running on your build, since different images make different choices here. Also look at the ALSA buffer and period settings for the device: smaller periods mean lower latency at the cost of more frequent interrupts, and on these boards the CPU cost of small periods is usually negligible compared to the emulation workload itself.
Mind the display side of sync
Audio latency is only half of perceived sync. If the display pipeline adds several frames of delay, which is common with certain scalers, shaders, or display processing, then perfectly tight audio will still feel wrong because the picture is late. Before chasing the last milliseconds of audio latency, check whether the video chain is the real culprit. Game mode on the display, minimal shader stacks, and the frontend's frame delay or run-ahead features all reduce video latency, and reducing video latency makes a given audio latency feel smaller. The goal is not minimal audio latency in isolation. It is minimal total latency between your input and the combined audiovisual response, because that is what your hands actually perceive.
Stability testing under real conditions
Latency settings that survive the menu will not necessarily survive gameplay. Menus are quiet and undemanding. A boss fight with dense sound effects, a racing game with continuous engine audio, or a shader-heavy core running at full tilt is where marginal buffer settings reveal themselves as crackles and pops. Test with the most demanding core and the most demanding game you actually play, for at least fifteen minutes, after the board has warmed up. Thermal throttling on passively cooled boards changes timing behavior as the session goes on, so a setting that is clean in minute two can crackle in minute twenty. If you find yourself re-tuning seasonally as ambient temperatures change, that is normal for small boards, and it is a sign to leave one step of safety margin rather than running at the absolute edge.
Work the stack top to bottom: emulator latency setting first, then the audio driver, then resampling and system buffers, and finally the display chain that frames the whole perception. Tune in steps, test under real gameplay load, and keep one step of margin. The reward is a game that feels connected to your hands again, which is the entire point of playing the originals.
Related Guides
- Reducing GPIO Input Lag on Retro Emulators: Input lag is the delay between pressing a button and seeing the result, and on a Raspberry Pi retro gaming build it accumulates from every stage: the
- Overclocking Core Frequencies on RetroPie Consoles: RetroPie turns a Raspberry Pi into a retro gaming console, but some emulated systems demand more CPU than the Pi delivers at stock speeds
- Overclocking Core Frequencies on RetroPie Builds: RetroPie on a Raspberry Pi emulates classic consoles, and emulation is brutally CPU-intensive: the Pi must simulate every cycle of the original
- Setting Refresh Rates to Eradicate Micro-Stutter: Micro-stutter, the barely-perceptible but maddening irregularity in scrolling and motion, ruins retro gaming on the Raspberry Pi more thoroughly than