libretro: report exact SPG refresh rate

[Immersion95]

This is a small follow-up to #2396

The SPG-based AVInfo update currently derives the reported refresh from the scheduler's integer Line_Cycles, which includes the scheduler's internal quantization.

For Dreamcast VGA:

200000000 * 858 / 27000000 = 6355.555...

Because Line_Cycles is stored as an integer, it is truncated to 6355, producing:

200000000 / (6355 * 525) = 59.94530 Hz

The exact video refresh from the live SPG totals is:

27000000.0 / (858.0 * 525.0) = 59.94006 Hz

The practical difference is very small, but it affects the reported value:

• 59.94530 Hz rounds to 59.95 Hz
• 59.94006 Hz rounds to the expected 59.94 Hz

This change leaves the integer-based internal scheduler unchanged and only reports the exact SPG video refresh through libretro AVInfo.

[sonninnos]

Please provide proof that audio buffer saturation works better after this change. The only thing that actually matters is that audio is generated at the same rate.

[Immersion95]

Please provide proof that audio buffer saturation works better after this change. The only thing that actually matters is that audio is generated at the same rate.

There's no proof that I can provide. I just saw the value 59.94530 and thought it wasn't correct.

I'll close the issue if it's not useful.

[sonninnos]

The only way to be sure is to actually use the core for long periods (many many minutes) and pay attention to frame stutters and drops and audio stats.

Sure the current one can still be "wrong" and be accurate enough, and getting it more precise can do no harm. But it needs to be tested and confirmed, since changing this value will not change the underlying code the audio is generated at. And in all different modes that will use different rates (default NTSC, Naomi, 240p).

[sonninnos]

I did some tests and all values seem to behave just as fine, since the results are indeed very close. So LGTM.

[Immersion95]

Just to clarify: neither your PR nor mine changes the core's effective pacing. On my setup, the measured frame rate still remains at 60.0 FPS. They only change the refresh rate reported through Core AV Info. Is that intentional?

[sonninnos]

Like I said

changing this value will not change the underlying code the audio is generated at

Frontend is doing the final resampling to display rate, and the harder the job the further the reported fps rate is from the effective audio rate.

[Immersion95]

Like I said

changing this value will not change the underlying code the audio is generated at

Frontend is doing the final resampling to display rate, and the harder the job the further the reported fps rate is from the effective audio rate.

Got it, thanks. So the 60.0 value I’m seeing is the frontend’s final presentation/resampling rate, while Core AV Info only reports the core’s nominal refresh rate.

In that case, this PR is intentionally limited to reporting the exact SPG refresh. Changing the core’s effective pacing or audio generation would be a separate change.

I'm using Sync to exact framerate btw, that's why I was surprised at the 60.0 fps value on my 120hz VRR screen.

[Immersion95]

Should I target dev branch ?

[sonninnos]

Please merge this, thanks.