juce_millisecondsSinceStartupHiRes & QueryPerformanceCou

#1

Hi,

I am using Juce’s Time::getMillisecondCounterHiRes in a real-time audio application to time control events.

I noticed that the current win32 implementation relies on QueryPerformanceCounter which, according to a microsoft KB article can sporadically leap several seconds forward under heavy PCI load, with certain chipsets.

The article can be found here:
http://support.microsoft.com/?scid=kb%3Ben-us%3B274323&x=15&y=15

So far, everything works fine on my machines, but I was wondering if the proposed microsoft fix (checking QueryPerformanceCounter return value against GetTickCount’s one) could be added to the juce code base. This would make real-time juce applications more robust, even on crappy machines…

Thanks.

#2

Jeez, what a horrible bug! It can’t be very common, can it?

As the getMillisecondCounter call is supposed to be fast, I’m very reluctant to slow it down by doing all that checking every time it gets called…

#3

Glad we agree on the beauty of this bug :slight_smile:

I don’t know if it’s very common, but apparently, it was serious enough to stop the virtual dub’s guys from using QueryPerformanceCounter. They just went for timeGetTime and forgot about the microsecond accuracy altogether:

http://www.virtualdub.org/blog/pivot/entry.php?id=106

The page above also contain the following line:

If you don’t really need high precision, you can use GetTickCount(), which has terrible precision on Win9x (55ms), but it’s reliable, and it’s fast, since it just reads a counter in memory.

That claim seems indeed to be confirmed by this benchmark:

extracted from this rather extensive Dr Dobb’s article on win32 timings:

Since on WinXP, QueryPerformanceCounter is 80 times slower than GetTickCount, I’m not sure that adding a call to the latter and comparing the two values would be a performance blow…

#4

Wow. Very interesting, I didn’t realise the hi-res timer was so slow! I guess if I change it to use GetTickCount and do the check only for hi-res times, that’s actually a good solution. Thanks for the heads-up!

#5

First of all, thanks Jules for the quick 1.43 juce::Time update :slight_smile:

I’ve juste read this:
http://www.portaudio.com/docs/portaudio_sync_acmc2003.pdf

AudioMulch’s author, Ross Bencina also mentions the QueryPerformanceCounter problem there, section 7.2, while talking about midi event timing.

As a side-note for real-time audio newbies like me: this is a very good introductory paper.
It is primarily targeted at PortAudio users, but most of the stuff applies to any callback-driven audio API, like juce’s one.

And no, I’m not affiliated with the author in any way :slight_smile:

#6