I just updated, I think from 1.41 to 1.43, and now getMillisecondCounterHiRes() isn’t high resolution any more.
It used to work fine (except for the fact that the pitch bend algorithm I was timing was too slow!), but now it returns values of 15, 16 or zero ms, so fractions of milliseconds don’t exist.
Slow though it may be, my algorithm doesn’t reach THAT high…
This is Win 32, where the notable change is the PCI drift bug fix in getHighResolutionTicks().
Dave Heinemann
Hmm. I just tried this:
for (int i = 10000; --i >= 0;)
{
DBG (String (fmod (Time::getMillisecondCounterHiRes(), 1000.0)));
}
and it churns out plenty of sub-millisecond numbers, just as you’d expect… (?)
I tried that, and it only changed every 15 or so (92,92,92,92,…,108,108,108…).
Calling QueryPerformanceCounter directly works, so I’ll do that.
Thanks.
huh?? …all that it does internally is to call QueryPerformanceCounter (??)
There’s a bit of checking to avoid that drift bug, but that shouldn’t affect the result. Maybe you could stick a breakpoint in at the line
if (offsetDrift > ((int) hiResTicksPerSecond) >> 1)
hiResTicksOffset = newOffset;
…and see if that’s getting hit all the time? (Though I can’t think why it would do).
Aha. hiResTicksPerSecond is 2992550000, more than 2^31, so (int) is coming up negative and triggering the offset adjustment every time.
A couple of int64’s and abs ((float)) does it.
You must be using a nicer PC than me! Over here, I get just 3579545 ticks so the maths was no problem. Thanks for looking into it for me! I assume this’ll work:
[code] const int64 offsetDrift = abs64 (newOffset - hiResTicksOffset);
if (offsetDrift > (hiResTicksPerSecond >> 1))
hiResTicksOffset = newOffset;
[/code]
From what I’ve observed, Windows XP on a multiprocessor machine or 64-bit XP on any machine uses the RDTSC instruction when you call QueryPerformanceCounter. That obviously means that the clock frequency will be the same as the CPU clock.
On that same note, I just learned about this XP update that is supposed to fix performance issues on multiprocessor machines, including correcting for clock drift between the processors:
I don’t know that the timing resolution actually IS that good, kind of like double vs. float audio.
It was a nicer PC a few years ago. I still holds its ground against entry-level audio PCs, but it does only have one core, 32-bit.
Now I can get back to the eternal task of speeding up my code without making it sound too much worse, always looking for that rare optimization that makes it run faster and sound better.
