[Bug] VRR frame pacing regression after fast-forward; toggling the menu restores smoothness #19940

Is there an existing issue for this?

• This is a bug in RetroArch frontend
• I have searched the existing issues

Description

Games that initially run smoothly can become visibly stuttery after using fast-forward and returning to normal speed.

The uneven frame pacing can persist until I open RetroArch's menu and close it again. Gameplay then becomes smooth again, without changing any settings.

This affects multiple cores, including Flycast. It does not happen after every fast-forward operation, and its frequency depends on the core and video driver.

The September 27 build listed in Bisect Results restores normal frame pacing correctly in my tests.

Expected behavior

Disabling fast-forward should automatically restore the same smooth frame pacing as before fast-forward was enabled.

Opening and closing the menu should not be necessary.

Steps to reproduce the bug

1. Enable Sync to Exact Content Framerate with a VRR display.
2. Load a core and game that initially run smoothly.
3. Enable fast-forward for a few seconds.
4. Disable fast-forward and resume normal gameplay.
5. Observe that frame pacing can become uneven and remain uneven.
6. Open RetroArch's menu, then close it.
7. Observe that smooth gameplay returns.

The issue is intermittent; it does not occur after every fast-forward operation.

Version/Commit

7dddd2c

Bisect Results

Known working: e84ba6b (September 27, 2026). The first bad commit has not yet been isolated.

Present in the nightly version

Yes, this is reproduced in the nightly build

Platform & operating system

Windows 11 26H2

Affected Cores

Flycast, MAME and multiple other cores

Environment information

Hardware and video drivers

• NVIDIA GeForce RTX 3060 Ti 8 GB: observed with D3D11 and Vulkan.
• AMD Radeon RX 9070 XT: particularly noticeable with D3D11.
• VRR display with Sync to Exact Content Framerate enabled.

Configuration supplied for investigation

• vrr_runloop_enable = true
• video_vsync = false
• video_threaded = false
• fastforward_frameskip = true
• fastforward_ratio = 5.0
• audio_sync = true
• audio_threaded_pipeline = true
• audio_pipeline_fill_cap = true
• menu_pause_libretro = true

Known-working build

September 27, 2026, commit e84ba6b2f97ef94a86d510f0549227e9a624ea96:
https://github.com/libretro/RetroArch/actions/runs/36294923933

AI-assisted source review

I asked an AI to compare the working revision with the October 27 source at e8928377d1934208a5b03059b57674e002a8c61a.

It highlighted these later changes as possible investigation points:

• b655a205b1 — October 8: fast-forward frameskip decisions moved before core execution.
• bd24443dc4 — October 11: Shallow Pipeline Queue enabled by default, alongside audio queue regulation changes.

It also suggested comparing the state restored when leaving fast-forward with the state restored after closing the menu.

These are leads from source inspection, not confirmed causes or bisect results.

Relevant log output