PT8 CPU Usage

[Shan]

Myself and Bob O. have been looking at this same issue reported in this thread for quite some time now. I sent him this thread and hopefully he can chime in with his own findings so we can narrow the source. I have one test he requested on my end that I'll try and run today and let him know the results.

Hopefully we can pinpoint the source of this as it appears to be a common problem.

Shane

[Larry Younkins]

Shane,
Thanks for your efforts in resolving this. If there's more testing I should do just let me know. I have a few other systems I could press into service to test different hardware setups.
Larry

[DigiTechSupt]

I'm curious if any of your windows, when open, extend beyond the edge of the screen and, if so, does performance improve if you move them so they are not off the edge?

[Larry Younkins]

DigiTechSupt,
I don't see any significant change in the CPU usage when either window size is shrunk and moved off the screen. For the worst offender graphics card I tested (NVIDIA FX 5200), the CPU load was constant at 55% with no tracks and 64 sample buffer. One interesting observation I made is that the load is grossly unbalanced between the cores...one core is basically maxed out. I hope this helps.
Thanks,
Larry

[Bob Olhsson]

I'm seeing this more extreme in Vista. 7.4 didn't do it at all.

[bblue]

Originally Posted by Larry Younkins

DigiTechSupt,
I don't see any significant change in the CPU usage when either window size is shrunk and moved off the screen. For the worst offender graphics card I tested (NVIDIA FX 5200), the CPU load was constant at 55% with no tracks and 64 sample buffer. One interesting observation I made is that the load is grossly unbalanced between the cores...one core is basically maxed out. I hope this helps.
Thanks,
Larry

I've seen this too but I can't reproduce it right now.

Also, I've seen a variation of this with active but idle sessions. I have a multiple desktop manager (currently set to four), and sometimes I'll idle a session while flipped to another desktop window -- frequently with a couple of directories, task manager and perhaps core temp open. After awhile, sometimes I'll see one core in TM at almost 100% instead of how it started out with all cores floating around 40-50% (session usage at idle). When I switch back to the PT desktop everything is still working fine. Switch back to the TM desktop there still is high CPU usage on one core. Go back to the PT desktop and just play the session, go back to TM desktop and the core usages are back to normal (all four around 40-50%). It is not consistent and reproducible on cue, however.

Just now as I was trying to reproduce this and working with a Dverbs7 test session (at 257 Dverbs) I found a couple of bugs which might be related if it's somehow a graphics card issue.

I have two 1600x1200 monitors, with PT not maximized but instead stretched across the two monitors to the maximum size it will allow you to stretch (which appears to be 3200x1200 outer-edge to outer-edge of the PT frame). Using the Dverbs7 session freshly loaded and not record-armed, I minimized both the edit and mix desktops with the '_' in their respective upper right corners. Then while those are minimized go in to the View->Other Displays menu bar selection and disable or enable universe, track display or <hmm, forget the name>. Just keep repeating them. Immediately or eventually, PT will stop responding. Most of the time, the session is still running (confirmed by watching TM CPU usage), but no response from any UI mouse command and most keyboard shortcuts, and the menu bar items remain 'lit' as they do when a session is active. However, a ^Q or ^W will cause all menu bar items to go gray (except File, Window and Help, like with no session) but the session is still running.

When I do NOT have PT stretched to the max window size I am unable to duplicate this. Most of the time, the only way out is to kill PT in TM, but how it behaves at that time varies:

1. terminating outright
2. refusing to terminate at all but the session CPU usage stops. The process seems to go away by itself in about 15 minutes. Additional kill attempts do nothing.
3. coming up with a save/don't save/cancel dialogue box. I have just clicked don't save, but after that nothing happens (except that box going away) and you have to kill PT once or twice more for it to actually terminate.

This is in Vista 32 Ultimate SP1, PT8, NVidia 7600GT with the latest 181.20 drivers.

--Bill

[David Lang]

Hi,

I'm seeing similar CPU-hogging with PT 8.0, where Windows Task Manager reports 99% CPU usage in normal operation, dropping to roughly 40% when the edit / mix windows are minimised. I also note that minimising the entire ProTools application produces the same behaviour. The effect of this is that when ProTools is grabbing all the CPU resources, loading a secondary editing application - SoundForge, Recycle or whatever - takes ages - around 90 seconds on average in the case of SoundForge. Minimise ProTools, and load time for SoundForge falls to a more respectable 5 seconds. Looking at CPU usage in the 'Processes' tab of TaskManager, I can see that the SoundForge executable immediately appears in the list when it's launched, but gets 0 or 1% CPU allocation. Minimise ProTools, and CPU allocation for SoundForge jumps to around 40%, and it starts to load quickly.

My PT 7.4 system worked flawlessly. I'm running a Digi002 on Windows Pro XP SP3, using an ATI Radeon 7000 video card with dual screens.

David Lang

[Ludia]

Hi all,

Same here...eating away cpu time. I found out however something I didn't see posted yet.

I use dual monitors and normally I stretch the application to use both monitors so I can place the mix window on one and on the other the edit window. For this test I made my PT application on 3/4 of one monitor and minimized the mix and edit window. My cpu dropped to 0%...nice... If I open up now either the mix or edit window to max size within the PT application my cpu bumps up again to >50%. What I did now was increasing the size of one of the windows ( and the other totally minimized ) What I saw now was that the smaller I made the mix window the lower the cpu time went!! So cpu usage is equal to window size where 0 cpu is minimized and >50% cpu is max window size.

Seeing a lot of ppl having trouble with this I almost have to believe this is a little bug. To be honnest ( I'm in the software business as well and know how difficult it is ) if this is the only bug then a very deep bow to the software engineers at Digi.

My five cents, hope its usefull

Regards, Luc


PS: running Windows XP Pro 32bit SP3, nVidia GeForce 7650GS driver 178.24

[mytinycircus]

I have an odd symptom that I hoped LE 8 would cure but it didn't. I also hoped a new pc would cure it but it didn't.

If I'm working on a busy mix on my quad-core 6600 2G RAM with a normal amount of plug-ins I usually see about 25% cpu utilisation but after some time even if I'm not doing anything (or even in the same room !) the cpu utilisation shoots up to 75% and the system freezes and I have to kill the process. It's the pro-tools process which increases usage, I have nothing else running.

I've been through the XP setup recommendations but this still happens. Any ideas where I should be looking.

Cheers

[TOM@METRO]

Just for informational purposes;

I run 4 monitors and stretch PT across 3 of them. The 4th is for utilities and BFD2. 2 ATI video cards (550x).

I’ve moved things all over the place, minimized and maximized, and I can’t reproduce this issue on my system. I need a little more power than in 7.4 but nothing radical.