random Application suspended for half a second when Windows XP (32bit, SP3) plays a sound

Question

I noticed that the executation of different programs is sometimes delayed for half a second when windows plays a sound on (at least my) multi core machines (not in a virtual box). I tested 3 different computer hardware configurations. Also I have written a small c++ test application to recreate this problem. It just calculates some megabytes of nonsense in the memory and outputs the time, that was spended for this. This is done in a loop, so you continously get outputs. I uploaded this test program (including source code for self compilation, eg with GCC 4.7.2 from MinGW, if you fear malware in the executable) to here: http://daiw.de/share/PrintCalculationTimes.zip

On the following screenshots you can see what happens when a sound is played (via the sound settings in the control panel) while the program is executed: http://daiw.de/share/PrintCalculationTimesWithoutSound.png

http://daiw.de/share/PrintCalculationTimesWithSoundWithAnnotations.png (It does not happen with every click on the play button, but with multiple clicks it is quite easy to reproduce on my test PCs.)

Is this a well known problem? Can someone confirm this observation with the test case I provided?

Thanks for your attention.

Dobi

Answer 1

What I see is a 16ms jitter, not half a second delay. Also, I see it independently of any sounds being played (even in your screenshot this seems to be the case).

It would truly surprise me if playing some sounds prevented a (non-background-priority) thread from running, too. That would be a serious problem for literally thousands of computer games, all of which require both fluid animation and playing sounds all the time.

Considering that 16ms is the default resolution of the timer you use on your system, the result isn't surprising at all. It's just what you have to expect.

If anything, try using std::chrono::high_resolution_clock instead, or put a timeBeginPeriod(1) at the beginning of your program (needs -lwinmm ).

(Note that timeBeginPeriod(1) makes the scheduler execute more often globally , not only in your program, and not only for the lifetime of your program. If you use a laptop and run on battery, you may want to reboot after testing to conserve battery. Normally, one would reset to normal using endTimePeriod(1) , but since killing the process is the only way of ending your program that won't work.)