For those of us who run the AMD64 (x64) version of Windows XP 64-Bit Edition, the current build, build 1218, is a bit tricky to install. It's required to run Visual Studio .NET 2005, since the previous build 1184 was too old, but it has a tendency to blue-screen on startup until you trawl the newsgroups and find the hint to change the power management setting to Minimal Power Management. After that it mostly works, as long as you don't try to use Windows Media Player.
Anyway, I was doing some checks on the AMD64 build of VirtualDub 1.6.2, only to discover an annoying problem: the capture module wasn't capturing properly. In fact, the timing module was dropping an alarming amount of frames and was seeing the system clock run at half speed. I launched the 32-bit version to cross-check and sure enough, it too was seeing the clock run at half-rate. Doh! What the heck was going on...?
I tracked the culprit to QueryPerformanceCounter() returning goofy timings. This function is supposed to return a value that corresponds to a stable clock, whose frequency is given by QueryPerformanceFrequency() and whose rate is independent of CPU frequency changes. When I tried to test it at first in a console app QPC() was returning normal values, but then I noticed that:
- QPF() was returning 2000000000, which corresponds to the 2.0GHz speed of my CPU. This meant that QPC() was using the CPU timer. This was unusual since usually a 3.58MHz chipset timer is used.
- VirtualDub's capture module ran at normal rate when I ran the test program in the background.
I then realized what was going on. The capture test I was doing wasn't using more than 10% of the CPU, so the CPU was throttling to a lower speed -- and since QPC() was using CPU ticks, the tick counts returned were rising slower than they should have been according to QPF(). My test app took 100% of the CPU, so it forced the CPU clock back to full rate and eliminated the discrepancy. The obvious solution was thus to make VirtualDub's capture module always take 100% of the CPU.
VirtualDub only uses the high-performance timer in the capture module for the DirectShow and emulation drivers, so you're not likely to hit this given that there are no capture drivers that I know of for 64-bit Windows. However, I can imagine that this might cause other programs to act erratically, so if you think programs are running too slowly for this reason, changing the power management setting to Always On seems to fix it. This disables CPU throttling. Remember that if you pick a power mode that causes your system to blue-screen, you can reboot to safe mode to change it back.