Hrm, looking it up, at least in Windows a true refresh rate is not exposed, and unless you can go through the driver somehow, the only only Windows API for refresh rate query returns only an integer
, so... asking Windows seems to be unhelpful. I don't quite understand what's new about Windows 7 from the stuff you linked, this API has been there for ages, but maybe the display settings utility now uses its own API and displays only the rounded-down integer approximation? (I don't remember what the settings looked like in XP).
Anyhow, what I'd take away from that is that if you're going to do anything based on a fixed refresh rate, do this:
1. Measure it directly.
2. Provide the user with a manual override, and make sure they can use a decimal point.
I believe, though, that monitor refresh rates do tend to be quite stable. Once you've chosen it accurately you should be able to get reliable behaviour from it.
Tepples asked how long you'd have to measure it to get reliable results. The HTML5 test
I linked earlier seems to reach 4 digit accuracy in under 5 seconds, and settling on a 5th digit takes another 5 or 10 seconds. Because this kind of test tends to be subject to sudden spikes and interruptions, I believe it's important to filter outliers from your average when measuring; once removed the remaining points of data should be pretty consistent?
Thanks for testing it out. I've uploaded a short video of how nemulator behaves on my system (and this is typical of how it behaves on other systems I've tested on): https://youtu.be/3pmTXkYb1_s
. I just don't see (or hear) the issues you're describing, so I guess I'm at a loss as to why you're experiencing problems.
BTW, re: keyboard controls -- sounds like you enabled turbo (mapped to A and S keys, for the B and A buttons, respectively).
Ah, okay I must have pressed A or S by accident when I was looking for select/start. Seems better with that turned off.
As for the problems, it's stable most of the time but if there's a sudden spike it shifts a lot at once and I can hear the pitch drift.
I've attached a ROM that might help demonstrate the problem. Start the test tone in the ROM, and then play an A440 Hz reference pitch from some other device. The NES tone isn't exactly 440 Hz (there are accuracy constraints) but it's a constant pitch, and it will have a consistent beating according to how many Hz it's out of tune with your reference pitch.
Once doing this test, cause a spike in execution to happen. I guess it sometimes happens due to background processes, but it seems like I can reliably make it happen by switching to another windows for a moment, and then switching back. After the momentary lag listen to the rate of beating change as it suddenly drifts to compensate. I can easily measure differences of several Hz this way.
Like, probably wouldn't be very noticeable in to most people, especially when playing a game, but for me personally it's really objectionable to have the pitch drifting like this. Some people might like this way of syncing though, like it does at least produce "seamless" audio to match its target framerate, and that much is good. (I probably have a strong bias because I have an interest in musical instrument tuning.)
If you had a way to filter out lag spikes, it might make it possible to eliminate significant drift, too? Dunno how much you can do this without losing your 1:1 audio:video goal.