Since recently I have a strange performance problem in Windows 7 64-bit.
I am programming a JUCE stand-alone application. My audio calculations are quite CPU heavy. So it can happen, that I get drop-outs, because I cannot fill the audio buffer in time (typical stuttering sound as the result).
The strange thing is: The dropouts are actually affecting my whole Windows system. As soon as dropouts occur (even mild dropouts) Windows completeley freezes. Everything runs in snail-pace, clicking on the Windows Start menu has a lag of several seconds, etc. The audio sounds still fine though. Apart from dropouts once or twice a second.
I am pretty sure: it was not like that before. Before Windows did not freeze, when dropouts occured.
I want to add: my audio calculations use only one core. But I have a quad core CPU. So even if my audio calculations take all the CPU on the core, it should not affect the other three cores. And Windows should be able to run normally.
Or maybe that assumption is wrong? Can an audio thread running on one core, stall all other cores?
The thing is: when my application runs fine (no dropouts, Windows is responsive), the Windows Task manager tells me, that my application is using about 21% of my available quad-core CPU.
But if I slightly increase the audio load, the problem starts. In the Windows Task Manager I can then see, that all four cores suddenly jump to a load close to 100%. Yet the Task Manager still tells me, that my application is only using about 23% of the CPU time. I am confused.
Any idea, what could be the reason?
Has anyone experienced something similar?
PS: Yes, I already tried to turn it off and on again. Still the same problem
Just to chuck an idea out - are you using up a lot of memory with your app? Once Windows starts doing HDD swaps (due to running out of RAM) the entire system starts running at snail speed.
Just some things to test. Doesn’t directly address your problem, but may help you locate the cause.
0) Look for the obvious. Are you processing the data piecemeal? i.e. are you processing the block just read, or everything you’ve read so far?
I once saw some code that appeared to get slower and slower; it was processing all the data as the data was accumulating. Eventually the data took longer to process than there was time between blocks!..
- Replace your tricky code with empty (NOP) code (e.g. step through the samples, but don’t do anything with the values read, but write the data back to where your tricky stuff is writing it.) Does that work?
- Move your processing out to anther thread (and litter it with debugs)
Very odd that the other cores should be affected…
Could be something weird that the audio driver is doing with interrupts, I guess, but that sounds like a bug if so. Floating-point denormalisation can crush the performance of your audio thread, but I don’t think that would affect other cores. Like jonathonracz suggested, virtual memory thrashing is one of the few things that can ruin the whole system’s performance.
Thanks guys for your helpful feedback.
Don’t think it is the RAM. My system has 16GB and my application is only using about 150 MB. And I still have several GB free RAM.
About denormals: I am using FloatVectorOperations::disableDenormalisedNumberSupport();
But maybe I have some hidden dependencies on other cores (via the GUI?).
Or my audio driver is indeed messed up.
I’ll do some more debugging!
Unless you’ve got realtime-priority threads running on all the other cores, it shouldn’t be possible to stall the rest of the operating system.
If the CPU meter isn’t showing the other cores as being busy, then really the only thing that could be making the whole system glitch would be virtual memory thrashing or a driver bug.
Hmm… I see. No, no realtime priority threads on the other cores.
Honestly: Currently I am thinking some recent Windows Update must have messed with my system.
I let you know, when I have done more tests/debugging. Won’t be before Christmas, I am afraid. Which reminds me:
Merry Christmas to you all!