Fixing Periodic Emulator Stutter Caused by Refresh-Rate Mismatch

Refresh mismatch produces a characteristic cadence: motion is mostly smooth, then a frame is repeated or skipped at a regular interval because emulated frames and display refreshes do not map one-to-one. An FPS counter rounded to 60 can hide the difference between a console rate near 59.94 Hz, a display at 60.00 Hz, and other system-specific rates.

Periodic judder is only one kind of stutter. Shader compilation, storage access, thermal throttling, background work, and a core that cannot run full speed create different frame-time signatures. Measure before changing synchronization.

Step 1: reproduce with a constant-motion scene

Choose a scrolling background, attract mode, or camera pan that repeats. Disable fast-forward, rewind, run-ahead, recording, netplay, heavy shaders, and increased internal resolution temporarily. Close background capture and streaming tools.

Enable the emulator’s frame-rate and frame-time display if available. A stable average with a spike at a fixed interval supports cadence mismatch; irregular spikes tied to new effects suggest workload or shader compilation. If audio slows with emulation, the core may not be reaching real time at all.

Step 2: record the actual content rate

Do not infer refresh solely from “NTSC,” “PAL,” or the game box. Read the core’s reported frame rate and region. Arcade boards and some consoles use rates that are neither exactly 50 nor 60 Hz, and games can switch modes.

Record core version, content region/revision, reported frames per second, and whether the title itself intentionally runs at 30/25 frames while the video signal refreshes at roughly 60/50. Duplicate game frames can be correct; uneven presentation of those duplicates is the problem.

Step 3: measure the display path

In RetroArch, inspect the estimated or display-reported refresh under Settings → Video → Output and the active fullscreen resolution. Verify the operating system and display on-screen information agree. A laptop panel, dock, AV receiver, capture card, or television can negotiate a different mode from the one selected in the desktop UI.

Test windowed, borderless fullscreen, and exclusive fullscreen only where the platform exposes them. Compositors may schedule frames differently, but do not assume exclusive mode is always superior or even available. Change one mode at a time.

Step 4: establish a conservative VSync baseline

Enable VSync and return swap interval, frame delay, hard sync, black-frame insertion, and maximum swapchain settings to defaults. Libretro’s optimal VSync guide starts from accurate refresh measurement and uses dynamic rate control to keep audio and video synchronized.

Settings → Video → Synchronization → Vertical Sync
Settings → Audio → Synchronization

Do not disable VSync merely because tearing disappears in a screenshot; tearing is temporal and may not be captured. Conversely, Dolphin documents a special failure where VSync on a display limited to 30 Hz can force exact half speed. If the emulator runs at half speed, verify the display mode before treating it as cadence judder.

Step 5: use dynamic rate control within a small tolerance

RetroArch can slightly adjust audio resampling to reconcile the core and display clocks. Its rate-control design addresses the fact that exact audio and video rates differ. Restore default Synchronization and Dynamic Audio Rate Control before manual tuning.

The correction should be small and documented. Forcing PAL content to 60 Hz or changing emulated CPU clock to make a graph look smooth alters game speed, audio pitch, or timing. Do not “fix” presentation by making the emulated machine inaccurate.

If crackling appears, use a conservative audio latency and verify the measured refresh. Disabling audio sync can trade one visible cadence for buffer underruns.

Step 6: test variable refresh rate carefully

When the GPU, connection, display, driver, and frontend all support VRR, Sync to Exact Content Framerate can present rates close to the core without periodic duplication. Confirm the source rate lies within the display’s supported VRR range and that the feature is active in the display’s status—not merely enabled in a control panel.

VRR ranges and low-framerate compensation differ by device. Black-frame insertion, some capture paths, cloned displays, and window compositors may be incompatible. Keep a known fixed-refresh profile so a failed VRR experiment is reversible.

Step 7: exclude shader and workload stutter

If spikes occur only when a new effect appears, refresh alignment is not the primary cause. Dolphin’s official performance guide explains that specialized shaders can compile on demand and that Hybrid or Exclusive Ubershaders trade GPU cost for fewer compilation stalls. Apply emulator-specific recommendations rather than deleting shader caches repeatedly.

Test native internal resolution and default graphics first. Monitor CPU/GPU clocks, temperature, and memory pressure. A fixed periodic backup or power-management transition can mimic cadence. Never disable antivirus, system integrity protection, or driver signing to chase frame timing.

Step 8: compare rates with a simple cadence calculation

If content produces 59.94 frames each second and the display presents exactly 60.00 refreshes, the clocks differ by about 0.06 per second. Without compensation, their phase moves over time and eventually requires a repeated presentation. The exact interval depends on measured rates, not labels.

Use this as a prediction: if measured mismatch implies a cadence event at roughly the observed interval, the diagnosis is stronger. If spikes arrive randomly, investigate scheduling and load instead.

Step 9: validate audio, motion, and persistence

After changing one synchronization strategy, watch several minutes of the same pan, inspect frame-time history, and listen for crackles or pitch instability. Restart the frontend and display, then repeat. Test another title with a different native rate so a global fix for 59.94 Hz does not break 50 Hz content.

Save per-core or per-content settings when rates differ. Record display mode, VRR status/range, frontend/core versions, reported content rate, measured display rate, VSync, dynamic rate control, audio latency, renderer, and compositor mode.

Success means even motion, stable audio, correct emulation speed, and no recurring frame-time spike—not a counter that simply rounds to 60.

Related:

Sources: