Fixing Audio Crackling and Stuttering in Emulators
The game runs and looks fine, but the audio pops, crackles, or stutters. This is almost always an audio buffer or sync problem, not a broken emulator core.
Choppy or crackling audio, with otherwise-smooth video, points almost entirely at the audio pipeline — buffer sizing, driver choice, or sync settings — rather than the emulator core itself misbehaving.
Step 1: rule out a simple frame-rate problem first
If video is also stuttering, the underlying issue is more likely a performance problem (the core can’t keep up with real-time emulation) than an audio-specific one. Check the frontend’s on-screen frame-rate counter before assuming this is purely an audio issue — in RetroArch, this is under:
Settings → Onscreen Display → Onscreen Notifications → Display FramerateStep 2: increase the audio buffer size
Audio crackling with otherwise-smooth video usually means the audio buffer is too small, causing brief underruns whenever the host system is a few milliseconds late delivering the next chunk of audio. In RetroArch:
Settings → Audio → Output → Audio LatencyRaising this (in small increments — try 64 → 96 → 128ms) trades a small amount of additional audio latency for a much more stable, crackle-free stream. This is usually the single most effective fix.
Step 3: check the audio driver
Some audio backends handle timing more reliably than others on a given system. On Windows specifically, switching between WASAPI (shared or exclusive mode) and DirectSound can resolve crackling that persists even after buffer adjustments:
Settings → Audio → Output → Audio DriverWASAPI exclusive mode often gives the most consistent results, at the cost of the emulator taking exclusive control of the audio device (other applications’ sound will be muted while it’s running).
Step 4: check whether audio/video sync is fighting the buffer
Frontends commonly offer a choice between syncing to video refresh rate or syncing to audio. If Sync to Exact Content Framerate or a similar dynamic-rate-control feature is enabled alongside a very small audio buffer, the two settings can work against each other, each trying to compensate for timing drift the other is also adjusting for. Try disabling dynamic rate control temporarily to see whether the crackling stops — if it does, re-enable it only after the buffer size from Step 2 is already stable.
Step 5: confirm the host system isn’t simply overloaded
Audio thread starvation is a common symptom of general system overload — background processes competing for CPU time, thermal throttling, or a core that’s simply too demanding for the host hardware at its current settings (shaders and increased internal resolution both add real overhead). Temporarily disabling shaders and reducing internal resolution isolates whether this is a raw performance ceiling rather than an audio-configuration issue specifically.
Why buffer size is usually the real answer
Audio crackling is fundamentally a timing problem: the audio output device needs a continuous, gapless stream of samples, and any brief delay in supplying the next chunk produces an audible pop or stutter. A larger buffer gives the system more slack to absorb small timing hiccups before they become audible gaps — which is why increasing it, even at the cost of a few extra milliseconds of latency, resolves the overwhelming majority of crackling complaints without needing to touch anything else.