Frame Pacing and V-Sync: Why Correct Emulator Timing Is More Than Average FPS

An emulator can report 60 frames per second and still look uneven. Frame pacing describes when frames appear. A source console may run at a fractional or region-specific refresh rate that does not divide evenly into a 60 Hz desktop mode. The mismatch eventually forces a repeated or dropped host frame.

Average FPS hides the pattern. Ten frames delivered quickly and then a long pause can average to the correct number while motion visibly hitches. What matters is the distribution of presentation intervals and whether the emulator’s notion of time stays aligned with audio, input, and the display.

Source timing is part of the machine

Original systems derive video, CPU, and audio behavior from oscillator clocks and dividers. “60 Hz” and “50 Hz” are convenient labels, not exact universal rates. Regions, hardware revisions, arcade boards, handheld panels, and individual video modes can differ. Some software switches resolution or interlacing during execution, and some arcade games use refresh rates far from a desktop standard.

An emulator should advance according to the target machine’s clock relationships, not force the game logic to an assumed integer refresh. If it changes emulation speed to match the host without compensation, music pitch and gameplay timing can drift. If it preserves source speed while presenting to a mismatched fixed-rate display, it must occasionally duplicate, drop, or blend a frame, or tolerate a growing queue.

Multiple clocks compete

The emulated CPU/video clock, audio sample clock, host compositor, GPU queue, and monitor refresh all advance independently. Synchronizing video perfectly may require slight audio resampling. Synchronizing audio exactly may allow a video correction. Unbounded queues hide short stalls but add input latency.

Audio is especially unforgiving because a speaker needs a continuous stream. An underrun clicks or goes silent; excessive buffering delays every sound. Frontends often use dynamic-rate control to resample audio by a small amount as the buffer moves above or below a target. The goal is not to “improve” the soundtrack but to prevent two real clocks from drifting apart.

The operating system compositor may add another schedule. Borderless windows can be composited even when an emulator requests synchronization. Exclusive fullscreen, direct scanout, and compositor bypass are platform- and driver-dependent; a label in the menu is not proof of the actual path. Capture presentation timing on the machine being evaluated.

What V-sync does—and what it does not do

With immediate presentation, the GPU can replace the scanout image while the display is partway through a refresh, producing a horizontal tear where two emulator frames meet. V-sync-compatible FIFO presentation queues completed images for display boundaries, avoiding that tear. If a frame misses its intended boundary, it waits for a later one, which can create a larger interval and add latency.

Triple buffering is an ambiguous term. A queue with an additional image can keep the GPU busy and reduce stalls, but FIFO depth can also let old frames accumulate. Mailbox-style presentation keeps a newly completed image available while discarding an older queued image; it can reduce visible stutter and latency at the cost of rendering frames that never appear. The supported semantics come from the graphics API, driver, and frontend, not from the word “triple” alone.

V-sync does not repair an emulator that produces frames late, a CPU that cannot sustain full speed, a background task that interrupts execution, or a shader that compiles during play. It only controls how ready images meet display refresh.

V-sync and variable refresh

V-sync prevents visible tearing by presenting at display boundaries, but a missed boundary can delay a frame. Variable-refresh displays can follow a source rate within their supported range and reduce cadence mismatch. They do not fix an emulator that produces frames irregularly or a shader pipeline that compiles mid-game.

Variable refresh rate lets a compatible display begin refreshes at varying intervals within a supported range. That can display source frames with their natural cadence without forcing them onto a rigid 60 Hz grid. Below the panel’s minimum range, low-framerate compensation may repeat refreshes so the link stays in range; exact behavior depends on the display and GPU stack.

For emulation, VRR is most useful when the target rate is stable and inside the range. It cannot make a 30 ms late frame arrive on time, and it does not remove the frontend’s own queues. Some displays introduce different overdrive or flicker behavior at changing rates, so visual validation matters alongside timing graphs.

Cadence mismatch in concrete terms

Suppose a source produces slightly more than 60 frames each second but the host is locked to exactly 60 refreshes. The difference is tiny per frame, yet it accumulates. Eventually the source has produced an extra frame the display cannot show, so the frontend must correct the mismatch. A regular correction can appear as a small hitch every several seconds even though the counter remains near 60 FPS.

Running the display at a compatible multiple can help. A 120 Hz or 240 Hz mode gives more presentation opportunities and can represent some lower rates with repeated scans at consistent intervals. It does not automatically solve fractional differences, and the frontend must still schedule correctly. Integer multiples of a rounded label are not necessarily exact multiples of the source clock.

Buffers trade resilience for immediacy

Input becomes visible only after the game processes it, the emulator finishes the resulting frame, the GPU renders any post-processing, the presentation queue reaches that image, and the display scans it. Each queued frame can add roughly one source-frame interval. Larger audio buffers similarly protect against scheduling jitter while delaying sound.

Reducing buffers aggressively can lower best-case latency but increase underruns, tearing, or missed frames. The useful setting is the smallest stable pipeline for the actual workload and platform. Run-ahead, late input polling, and frame delay target different parts of the chain and can increase CPU demand; they do not excuse unstable frame production.

Shaders, compilation, and storage stalls

Multi-pass CRT shaders add GPU work and intermediate render targets. If the shader consumes nearly the entire frame budget, a small driver or compositor delay causes a missed presentation. Compile pipelines before gameplay where the frontend supports it and test the heaviest scenes, not only menus.

Disc access, texture-cache creation, background scanning, save-state compression, and antivirus or indexing activity can cause isolated stalls. A frame-time trace helps distinguish periodic clock mismatch from one-time compilation or I/O. Treating every hitch as “bad V-sync” sends diagnosis in the wrong direction.

Measure, then choose

Use frame-time graphs rather than an FPS average. Confirm the core’s reported refresh, desktop mode, fullscreen/compositor behavior, buffering, and audio resampling. The right policy depends on whether accuracy, lowest latency, stable audio, recording, or netplay is the priority. No single “sync” checkbox optimizes all five.

Measure at several layers when possible: emulator frame production, GPU submission and completion, presentation timestamps, display refresh, audio-buffer fill, and button-to-photon latency. A camera or latency sensor can validate the complete path, while software traces isolate where variance begins. Report median and high-percentile frame times plus the sequence of outliers; averages alone conceal cadence.

A disciplined configuration order

Confirm the core runs at full emulated speed without shaders or enhancement hacks.
Record the core’s reported source rate and select a host mode or VRR range that can represent it.
Choose one video synchronization strategy and verify whether the compositor changes it.
Tune audio resampling and buffer size until long sessions neither underrun nor drift.
Add shaders, rewind, run-ahead, recording, and overlays one at a time while watching frame times.
Test mode switches, sustained heavy scenes, save operations, and controller input.

For recording or streaming, the capture rate may be another fixed clock. A perfectly paced odd-rate arcade game can still require cadence conversion in a 60 fps video file. Keep the preservation master or timing notes distinct from a distribution derivative that targets a common media rate.

The correct result is not necessarily the lowest number on a latency overlay. It is a documented balance that preserves target speed, keeps audio continuous, presents motion predictably, and meets the player’s latency requirements without hidden drops or repeated frames.

Related:

Sources: