Fixing Audio Crackling and Stuttering in Emulators

Crackles, pops, repeated fragments, and short dropouts all mean that continuous audio did not reach the output device as expected. A small buffer can be the cause, but it is not the only one. If the emulator cannot produce frames in real time, audio starvation is a symptom of the performance problem rather than an isolated sound failure.

Change one variable per test and write down the original value. A latency setting that masks overload can leave the underlying frame pacing broken, while aggressive “low-latency” tuning can create the underruns it was meant to solve.

Step 1: classify the failure with a clean test

Use one known-good game and disable fast-forward, rewind, recording, netplay, run-ahead, heavy shaders, and increased internal resolution temporarily. Listen through a wired output if possible. This removes common sources of variable load and separates a Bluetooth transport issue from the emulator pipeline.

Enable RetroArch’s frame-rate display and observe whether video slows or judders when audio breaks. A stable counter does not prove perfect frame pacing, but simultaneous video and audio disruption strongly suggests missed real-time deadlines.

Settings → On-Screen Display → On-Screen Notifications
         → Display Framerate

If the core is below its expected rate, reduce enhancement settings first. Increasing the sound buffer cannot make an overloaded CPU or GPU emulate faster.

Step 2: restore a conservative audio latency

RetroArch exposes Audio Latency in milliseconds. Libretro’s synchronization guidance notes that a buffer set too low can cause stutter or poor audio, and documents 64 ms as a deliberately conservative default.

Settings → Audio → Output → Audio Latency

Return to 64 ms if the value was tuned downward, restart RetroArch if the interface requests it, and retest the same segment. If crackling persists while performance is otherwise stable, raise latency in modest increments until the output is clean. Record the lowest stable value rather than prescribing 96 or 128 ms to every device; backend scheduling and hardware differ.

The trade-off is real: a larger buffer tolerates longer scheduling delays but makes sound respond later. Once stability is proven, lower the value one step at a time if responsiveness matters.

Step 3: repair refresh-rate synchronization before disabling it

RetroArch’s dynamic rate control is designed to reconcile audio timing with video refresh differences. The official troubleshooting guide warns that accurate video_refresh_rate configuration matters and that disabling rate control can make simultaneous audio/video synchronization difficult.

Check Settings → Video → Output for the reported or estimated display refresh rate and Settings → Audio → Synchronization for synchronization and dynamic rate control. Restore defaults before experimenting. A display running at 59.94 Hz, 60.00 Hz, or a variable refresh mode can produce different drift behavior even when all are casually called “60 Hz.”

Do not disable synchronization permanently just because one quick test becomes quiet. That may exchange crackles for periodic dropped or duplicated video frames. If toggling it changes the symptom, capture the refresh values and consult the frontend’s current synchronization documentation.

Step 4: isolate the audio backend

Available drivers depend on operating system and how RetroArch was built. Libretro documents WASAPI, XAudio, and DirectSound on Windows, and ALSA, PulseAudio, JACK, or other choices on Linux builds. The installed Settings → Drivers → Audio list is authoritative for that binary.

Save the current configuration, select one supported alternative, fully restart RetroArch, and repeat the identical test. Do not install unofficial “audio driver packs.” On Windows and macOS, normal system audio drivers or the hardware vendor’s signed package are the safe source; on Linux, use the distribution’s package manager.

Changing both driver and latency together destroys the diagnostic value. First test the alternate backend at a conservative buffer, then tune only if it is stable.

Step 5: check device format and wireless behavior

Test the operating system’s built-in speakers or a wired headset. Bluetooth adds codec buffering, radio interference, reconnection behavior, and sometimes sample-rate conversion. If only Bluetooth crackles, remove and re-pair the device using the operating system’s supported workflow, reduce interference, and update firmware only through the manufacturer’s official tool.

Avoid forcing exotic sample rates. RetroArch’s resampler exists because core audio rates and host output rates differ. Return Settings → Audio → Resampler and output rate to defaults before trying a different resampler quality. An unsupported device format or a third-party virtual mixer can add another conversion layer; bypass virtual cables, equalizers, streaming software, and DAW routing during the baseline test.

Step 6: find load spikes rather than average load

Audio threads can miss deadlines even when an average CPU graph looks moderate. Thermal throttling, shader compilation, power-saving modes, background backups, antivirus scans, and screen recording can cause short stalls. Test the same scene after closing optional workloads and connecting a laptop to power.

If crackling begins only with a high internal resolution or shader, lower that feature until headroom returns. If it begins on first encounters but disappears on a second run, shader compilation may be involved. Do not assign real-time priority or disable operating-system security controls as a “fix”; those changes create stability and security risks while concealing the application bottleneck.

Step 7: collect a log and a reproducible matrix

RetroArch can write a verbose log through Settings → Logging → Logging Verbosity and Log to File. Reproduce only long enough to capture the fault, then disable verbose logging if it adds overhead. Record:

RetroArch and core versions;
content and region;
expected and observed frame rate;
video refresh rate and VSync state;
audio driver, output device, latency, and resampler;
whether wired output and default shaders reproduce the issue.

If the same content is clean in another core at default settings, report the difference instead of copying random configuration files. If every application crackles through the same device, the fault is below the emulator and belongs in operating-system or hardware troubleshooting.

A stable result should survive a restart

After finding a clean configuration, restart RetroArch and replay the test. Then restore shaders, enhancements, wireless audio, or recording one at a time. Save a per-core override only when a core genuinely needs it; global changes can degrade systems that were already correct.

The reliable order is performance first, conservative buffering second, refresh synchronization third, and backend/device isolation after that. This treats crackling as evidence from a timing pipeline, not as proof that the emulator core is broken.

Related:

Sources: