Dynamic Rate Control

[Hydro5]

Dynamic Rate Control is a means of achieving near perfect sync in emulation. It's used in the RetroArch project. It would be excellent if PCSX2 added DRC as well. Read more:

https://docs.libretro.com/guides/optimal-vsync/ https://github.com/libretro/libretro.github.com/raw/master/documents/ratecontrol.pdf

[ramapcsx2]

I love the full blown dissertation on the audio topic xD However, in pcsx2 we're very demanding even on modern machines. Frame rate regularly dives below full speed due to a lot of factors that can't all be compensated for. For example: A level change in a game might trigger recompiler flushes, CPU wait cycles because the HDD is still fetching data, who knows what kind of effect the GPU is struggling to perform.. So in our case we would have to factor this in and be a bit leaner on the demands.

The audio rate control could be tried. We have a very unscientific version of this implemented right now that uses the soundtouch library for "dynamic tempo" adjustment. This changes the audio sample length without affecting pitch but it has a lot of drawbacks (like requiring a pretty big buffer).

It would be a pretty nice project for someone that has a couple hours to spare on this :) Collaboration can be done on IRC, as usual: #pcsx2dev on Efnet.

[mirh]

Wasn't this achieved in #5488? And/or why wouldn't the current timestretch solution that has been a thing ever since SPU2-X be up to par?

On conventional computer hardware, there is no perfect way of knowing the real monitor refresh rates and audio sampling rates either due to tolerances on oscillators.

And maybe I shouldn't take an issue with some decade old paper, but this sounds just so much misleading.

The whole thing is painted as a clever solution to high refresh rate variance. Which it is to be clear, assuming that was a problem. Air/giga didn't flex so much back in the day, but kudos here for formalizing the idea (which I do grant to be a great thing).

But what everybody is using this for, is nothing of that (in fact, it even smells specious to imply that display tolerances variability today, should concern the emulation of stuff that existed when its output could be influenced by mains frequency). Even the synthetic test at the end embodies a different use case than the one stated.

They aren't targeting the NES timings (which is 60.0988 Hz for some intriguing reason) and then "unfortunate flukes happen". Actually, they somehow are not even sticking to the original NTSC refresh rate to begin with (some lazy googling tells me 59.88 Hz might be some rounding error in OSX).

What they are doing is instead starting from the observation that the spirit of OG console smoothness (proper pacing, and no tearing) would require syncing to VBLANK, and from there reasoning backwards to what they could even try given the fixed unchangeable non-adjustable frequency of their current displays. And by all means this is still a hell of a fair issue, when you have to bow down against whatever are the limitations of some close/embedded platform.

But it's just bollocks instead when it's PCs that you are talking about: EDID can be actually overridden everywhere. And I don't doubt that exceptions exist, but even before VRR the great majority of monitors and TVs should be able to accept variations in the range of 1% of their nominal refresh frequency (in fact, some panels even directly offer 50Hz out of the box).

This was like one big XY problem, where the asker also straightaway replied to himself cutting a discussion on the real matter. The ideas explained in #2059 should have been far more of a concern for "hard purists".

[refractionpcsx2]

I don't think this is really relevant anymore, audio (via timestretch) and video can be synced to vsync and has VRR support for variable rate changes.

So yeah, it pretty much does what the vague description says for DRC.