Reduce latency for frequency-based frame sync

[nyanpasu64]

Frequency-based framesync is more precise and doesn't drift back and forth relative to the target phase, so we can safely run it at a lower latency without risking tearing or falling a frame behind.

This should be 100% safe in regular operation in a fixed video mode, and mostly safe when the game switches between 240p and 480i (safe unless externalClockGenSyncInOutRate is called too late after a mode switch, or fails).

We allocate 0.125 frames of latency in steady state. This should be more than the (up to 0.071+ frames of) buffer we lose when input slows down from 262.5 to 263 lines, before we respond and change our output rate to match.

(This new measurement of 0.071+ frames is larger than the maximum I previously observed at https://github.com/ramapcsx2/gbs-control/pull/405#issuecomment-1407776551. Hopefully 0.125 frames of buffer is very unlikely to be exceeded; if it ever is, the appearance and input latency will suffer since we roll over to a full frame of latency and have to work our way back down.)

• [ ] Should I increase the target latency even further? Or drop this PR entirely? (If so, I'm keeping this patch locally.)
• Ideally we would make runSyncWatcher() respond to 240p/480i changes faster (previously researched in https://github.com/ramapcsx2/gbs-control/pull/405#issuecomment-1418912768 timingAdjustDelay), so we can safely reduce frame sync latency even further.
• Ideally users could reconfigure their desired target latency? Or is this too complex/esoteric to expose on the web UI, and fine as a code change?

[ramapcsx2]

I've no idea about the tuning, but it should be done for the user beforhand / no need to put config items in the UI.

[nyanpasu64]

Probably not worth upstreaming, most users don't care about reduced latency, and I'm worried about breaking people who switch between 240p and 480i. I'm thinking the default configuration should be conservative and avoid breaking in any use cases, whereas people who know what they're doing can lower their latency locally.

And the "GBS-C has 4ms of latency" figure is already widely reported, and changing it to a lower but nonzero latency might cause confusion (since you can have drifting latency, 4ms, or 1-2ms depending on version and configuration).

[ramapcsx2]

Let me just add that the exact number of milliseconds is not important, when it comes to below 16ms or so. A difference of 3ms is simply irrelevant ;p