FBNEO fast forward; rewind throws off sound and video synchronization

Lately I’ve been having issues rewinding or fast forwarding CPS2 games using FBNeo.

I should note that I also use Run-ahead.

What I experience is that the sound I hear has nothing to do with what is happening on my screen if I use the fast forward or rewind functions.

This issue is not present in the MAME core. Maybe something to do with Run-ahead? This is something that is relatively new. Things had been working perfectly before the 1.0 update (I think that’s when it started). Thanks.

1 Like

Do you use ‘second instance’ with runahead? If so, try turning it off. If not, try turning it on.

1 Like

Indeed, this is apparently due to rewind and runahead using savestates with mismatching sizes, ending up breaking this libretro api rule in the process.

I applied a fix, it should be fine now, thanks for the report.

Edit : reading that rule again, actually it’s something different, but anyway it seems retroarch can’t deal with runahead+rewind if savestate sizes for both context keep changing


I noticed this same symptom anytime I entered a game with Run Ahead enabled. I lowered frame delay to 0 and it was still occurring. Previously I had frame delay set to 14 and everything was fine!

I rolled back to the previous version Core and all that you described went away and I can now play with Run Ahead at 2 Frames + Second Instance plus Frame Delay of 14.

I previously experimented with using Auto Frame Delay together with manually optimized Frame Delay but I stopped doing that and just stick with manual settings now.

@Cyber Assuming you are talking about the same thing, this was an issue with rewind+runahead. I managed to fix it by only keeping the highest size (the new core should be available from the buildbot by now ?), but i think RA is probably doing something wrong here, my guess is that it’s somehow truncating runahead savestates if rewind savestates are smaller (which was the case for cps2 games here).

On a sidenote, i’m also noticing i should probably add rewind-awareness to the RETRO_ENVIRONMENT_GET_SAVESTATE_CONTEXT api call i introduced in https://github.com/libretro/RetroArch/commit/e9d67f2bbe01f3fe66de5eda6430bccfba95b663 . Rewind probably has similar expectations to “runahead same instance” for savestates.


My issue had nothing to do with rewinding or fast forwarding but the symptom was the same as described by @c9f5fdda06.

I didn’t need to use rewind nor fast forward to experience this. It just occurred on its own with the settings I described in my post, which worked fine before I updated the core. The game I noticed it in was Street Fighter II Hyper Fighting.

When I disabled Frame Delay, the issue appeared to stop during the attract mode, however as soon as I put in my coins and entered a match I began hearing audio which didn’t match the video.

I think at that point going into the Menu and disabling Run-Ahead might have resulted in whatever was on screen immediately switching to match what was being heard.

So basically Run-Ahead and Frame Delay were completely broken for me in the latest FB-NEO Core.

A rollback of the core to the backed up core resolved this completely for me.

I’m not familiar with frame delay, does it somehow rely on the savestate system too ? Is there any amelioration after yesterday’s fix ?

On a sidenote, you mentioned second instance runahead, but the only mode we officially support is single instance, so i’d recommend using that.

What’s the version of that backed-up core ? (i want numbers + commit hash)


No, frame delay is unrelated to savestates, so maybe a red herring here.

1 Like

I figured out the problem, this is unrelated to frame delay, i could trigger it by simply activating second instance runahead. This was due to some savestate size verification mecanism i implemented recently.

It should be fixed with https://github.com/libretro/FBNeo/commit/781281878c0b28c0fff3b07a7c22152d56294991

Thanks for the report !


Well up until that core update second instance had been working flawlessly for me from the time I started using Run Ahead and Frame Delay many months ago.

If I switch it off I hope I won’t start getting “audio problems due to loading state” or any other performance issues.

FinalBurn-Neo (v1.0.0.03 a237594)

Single instance runahead is the mode we officially support because it’s the only mode also available in standalone FBNeo. Any issue about it will be fixed as long as it’s reported. I can’t guarantee the same for second instance.

Dwedit (author of the runahead implementation) made some interesting statement about single vs second instance here and there. Some people have indeed been using second instance because they think it’s faster, but actually it seems to be a placebo effect only happening when you are not pressing any input.

That’s indeed a version from before i implemented that verification mecanism.


Thanks. In my case I enable second instance to avoid “audio problems due to loading state” not necessarily for any perceived performance benefit.

Stupid question: How would I or a relatively casual user know which cores support Continuous Audio and which ones don’t?

1 Like

if you enable runahead and the audio sounds bad (EDIT: aside from simply not being able to run fullspeed, of course), it’s discontinuous :stuck_out_tongue:


Not sure there is a definite list of symptoms. In FBNeo before we fixed all those bugs, i’ve seen the music playing very fast, or randomly stopping.


Thank you so much for looking into this I can’t wait to try it out. :smiling_face_with_three_hearts:

1 Like

It should already be available from the buildbot ?


Yes it is and it works perfectly with or without Second Instance! Thanks again!