What is the most reliable way to measure time intervals?
The documentation warns against trying to measure time intervals using methods which depend on the system time because the system time can change at any moment.
And precisely for this there’s a method: getMillisecondCounter(). It returns a “monotonically increasing value which is unaffected by changes to the system clock.” Perfect!
But then there’s a warning: “Being a 32-bit return value, it will of course wrap back to 0 after 2^32 seconds of uptime, so be careful to take that into account.” And it is suggested that, if one needs 64-bit time, one uses currentTimeMillis() instead - but this method returns the system time.
Now, 2^32 seconds are more than 136 years. Is guess the documentation is wrong here and this should read 2^32 milliseconds, which are about 49 days?
Also, instead of suggesting using currentTimeMillis(), shouldn’t the documentation suggest using getMillisecondCounterHiRes() instead, if one needs a larger temporal range? Or does getMillisecondCounterHiRes() just have more precision but also the problem of “wrapping back to 0” after some days of uptime?
The documentation states that “This is a similar idea to getMillisecondCounter(), but with a higher resolution.”
What does “similar idea” mean exactly? How much higher resoulution does it have? Does it also have the problem of wrapping back to 0 after some days? If all the 32 additional bits are used for the increased resolution, I would expect it to also wrap back to 0, but none of this is specified.
if your question is about the audio thread the best way is just to count samples in processBlock. if this is about GUI stuff the usual class to use for animation is juce::Timer. it’s pretty good for most stuff but it has framedrops at all fps so you might want to use the highPrecisionTimer instead. it uses more cpu but has way less frame drops. it uses its own thread and inserts its paint-requests async into the message thread
Thanks! I need to measure time intervals on the message thread and want to know which method can give me a time value which is both unaffected by changes to the system clock AND will not wrap down to 0 after just some days or months after system startup.
With regard to the idea of using a highResolutionTimer for async paint-requests to the message thread, I’m under the impression that that would be of little help:
Good suggestion! It seems that it’s what JUCE uses internally, as far as I can tell by briefly looking under the hood. Still, I would love to know how the JUCE methods work exactly, since they are so convenient to use. If anyone from the JUCE team could shed some light here that’d be nice.
