CPU core number 8 peaking at 100% every 18 seconds under Pro Tools 10/11

[gazzerb]

I have a problem with one of my CPU cores (core 8) overloading to 100% every 18 seconds when I run PT, which I believe is the cause of the presence of some prominent clicks and crackles in audio.

The overload happens in both PT 10 and PT 11, cycling every 18 seconds before I have even loaded a session.

I'm running Windows 7 Ultimate 64 bit with Service pack 1 on an Intel i7 975 at 3.33 Ghz (4 cores, 8 logical) with 12 GB RAM.

Any ideas as to why this is happening and what can be done about it?

[mjslakeridge]

You may want to disable hyperthreading in your BIOS. Then your system will see only the 4 physical cores. From what I have read here on the forum, some PT installations run best with hyperthreading disabled, while others run best with it enabled. Depends on various factors within your hardware.
Is it only ProTools that causes the cpu spike? Have you tried some stress testing software such as w-prime or super-pi? Perhaps the core is bad. Have you overclocked the processor? If so, undo that and run it at the stock settings.

[Darryl Ramm]

Start at the "Help us Help You - READ THIS Before Posting!" link above on this end every DUC page.

Post a Sandra report. Indicate what drive partitions shown on that report are where you have Pro Tools installed, which you are using for audio/sessions and where you have any VI samples installed.

What interface are you using and what driver version?

Is your system fully optimized? Do every last thing no matter how painful or silly sounding. e.g. Is your WiFi disabled? Bluetooth disabled? USB power management disabled? etc. etc. Do every last thing now, you can try backing some off later if you need to. Don't assume, go check everything again.

Make sure there are no other programs running that don't need to be and make sure that any antivirus software is uninstalled or fully disabled. In fact check that antivirus software first.

For sessions with crackling etc. problems. Describe the session, what sample rate, number of tracks, which plugins and number of instances etc. Have you done basic troubleshooting steps like trashing prefs and databases? For Pro Tools 10 what IO buffer size are you using?

What third party plugins are installed? If other things don't help then you want to suspect those plugins (even if just installed but not instantiated in your sessions) and temporarily remove all third party plugins from the plugin folders and see if the problem goes away.

[albee1952]

Good advice above. I suspect there is some software running in the background. Possible culprits include networking(disable it to test), anything that runs on a schedule(backup software, anti-virus, etc) or maybe even a virus, trojan or malware has found a new home in your machine(which can happen, even if your machine never connects to the internet as someone might bring you files on a hard drive or pen-drive...a lesson I learned the hard way)

I second the idea of testing with hyperthreading OFF and ON as I do think its a "case by case" thing, as well as testing with ALL cores assigned to PT, vs leaving 1 or 2 dedicated to system processing(my own rig seems best with all cores given to PT, but others have different results)

As a staunch user of Acronis for drive imaging and cloning, I did go into Startup items and uncheck it

[gazzerb]

Thanks for your replies. I'll have time tomorrow to try out some of the fixes though, to be honest, although they are always quoted as possible sources of problems I've never known the anti-virus software that I use to cause any problems in any PC system that I use - and this seems to be no exception in this case, since disabling it changes nothing - the problem persists.

To address a couple of questions asked above, no, this type of behaviour on a core does not occur in any other software I use on my PC. It is unique to PT and I am not overclocking my CPU.

From reading this, and other forums, it would appear that the most likely culprit would be a plugin (or plugins), so I'll start with that approach first.

If it turns out to be something more complicated, I will of course supply fuller details using Sandra etc., but I was hoping for pointers to the likeliest cause(s) first so that I could investigate and eliminate them, or even better, someone to reply who had experience of a similar problem and a fix.

Thank you again for your suggestions.

[gazzerb]

An update on this issue:

I did some further research on this issue and it turns out to be quite common with those using USB Audio devices.

Personally, I am using and Avid Mbox into an USB 2 port and I have confirmed that this is the root of the problem both by routing other processes through the Mbox (which causes the same spikes) and by unplugging the Mbox (which stops the spikes totally).

The issue is known to Microsoft in an article entitled:
There is high CPU usage when using a USB audio device connected to a USB 2.0 EHCI host controller

In this article, the phenomenon that I (and others) are experiencing is accurately described (although the cycling with me is 18 seconds rather than 15 seconds).

Apparently, this problem occurs because of an issue in the usbport.sys driver

The link to the article is

http://support.microsoft.com/kb/981214

There is also a hotfix for Windows 7 users (although not for Win 8 users, who apparently are experiencing the same issue).

But, as always, there is a catch: the hotfix won't run - the Windows Update Standalone Installer comes up with the message 'The update is not applicable to your computer'. Other users have reported the same problem with the hotfix, while it works perfectly for others.

Why this is so is a mystery. A phone call to Microsoft was not enlightening, but they stated they would help me with the problem - for a payment £65, which I declined.

I have one other option to try - disabling HPET (The High Precision Event Timer) in the BIOS, which cured the problem for one user but it seems that opinion is divided as to whether doing so would adversely affect other processes that may use HPET.

Since my only other alternative is to pay Microsoft £65 to try and solve a known problem with their USB drivers or to shell out on a non-USB audio audio interface, I may well give the HPET disabling a shot since I can always enable it again in BIOS should problems occur.

I will report back after I test the HPET disabling.

[gazzerb]

It proved impossible to disable HPET from the BIOS - the option doesn't seem to exist (My motherboard is an Asus P6T Deluxe V2 running the latest BIOS). I tried disabling the HPET driver from within device manager, but the problem persists.

Therefore, apart from investing money in a new interface that doesn't run on USB 2, I seem to have run out of possible fixes.

Since it has been already been flagged up by Microsoft as a problem that can arise with any USB 2 audio interface running on Windows, I'm guessing that that the number of users affected by this issue is huge, but that most are unaware of it because they are not running CPU usage/monitoring software to examine activity on individual cores.

[Bill Denton]

... but that most are unaware of it because they are not running CPU usage/monitoring software to examine activity on individual cores.

Not speaking specifically to you, but it seems a lot of people are getting far too hung up on performance monitoring.

Most performance monitoring is not terribly accurate in the first place...it is primarily useful for finding a deviation from a trend, not for finding an exactitude.

And you are not getting any "real time" information...what you see on the monitor happened some time before it is displayed on the monitoring app.

So, if your DAW is working properly, I wouldn't waste too much time worrying about what you see on inaccurate monitoring app...

[gazzerb]

But that's the problem Bill - I came across this issue while investigating why I sometimes get clicks in the audio when running PT, which seem to be happening when core 8 gets to 100%. If PT was working properly despite the issue, I wouldn't be posting here ...

[mesaone]

HPET timing should be left alone. I know there are many articles out there that talk about how changing it can improve performance, how it can improve DPC latency... Personally I think it's hogwash, and I suspect the reason you couldn't disable HPET is because it would cause instability. Invariant TSC is used as a system timer as well. Sometimes a simple restart will help things out much more than tinkering with timers and other "core" processes.