CPU Spike?

Re:CPU Spike? (rickpaul)

Tue, 09 Feb 2010 01:03:19 GMT

CJ has a point on the uneven number memory sticks, especially since you have a dual core CPU. I'd think you'd have seen other issues, too, in case of a problem from that, but who knows?

As for the RAM and x64, I didn't upgrade my RAM at all (at least not yet). If you've got 4 GB on your system, upgrading to x64 immediately lets you access almost 1 GB more than the 32-bit system did, while also letting individual applications access beyond the 2 GB limit that applications get under 32-bit Windows.

If you do want more, though, and your system only has four slots which are already used, then, yes, you'd have to replace some of the memory modules with larger ones. Make sure, too, and check on any limitations your motherboard and BIOS may impose. For example, my system limits RAM to a maximum of 8 GB, so I could replace my 4x1GB with 4x2GB at most, but, if I wanted more than 8GB, I'd need to replace my motherboard (unless there were a BIOS upgrade to get past that limit, but I think the limit is on the motherboard rather than the BIOS).

As for Pyro and the MP3 encoder, I don't know. I originally got the Cakewalk MP3 encoder as part of Cakewalk Pro Audio 9, and there have been utilities on the SONAR distribution disks to upgrade from that, even in SONAR 8.5. (That utility had a bug for x64, though, and I had to contact Cakewalk's technical support for a fix to get the Cakewalk MP3 encoder working.) Perhaps someone else who uses Pyro would know.

Rick

Re:CPU Spike? (CJaysMusic)

Mon, 08 Feb 2010 18:31:11 GMT

You know some pc's do not like uneven memory sticks. THey need to be balanced. 3 gigs may be giving you problems because you dont have matched Ram sticks.
You should have the same exact ram and they should be equal. Like two 2 gig sticks or two 1 gig sticks.
Maybe having 3 one gig sticks or what ever you have is the problem.
Cj

Re:CPU Spike? (Mesh)

Mon, 08 Feb 2010 14:36:22 GMT

Actually Rick, that's my next goal.....moving to the 64bit Win7 system. I'll have to get a new soundcard as my GL824 doesn't have drivers (yet) for the 64bit platform.....

If I do move to the 64bit platform, (to get more Ram) do I just replace my 4G's of ram with a larger number (maybe 8G's)? (I currently have 4 slots and each have a Gig in it).

On a seperate note, I was trying to export a song to MP3 last evening and I got an error saying (I think the word was "Unlock") MP3 Encoder.
I also have Pyro Audio Creator and updated it to 1.5.2. Before doing this update, I remember (about a year ago) exporting audio to MP3's without any issues with SPE7. So, my question is: can I use Pyro as my MP3 encoder? (I purchased Pyro when I got Sonar PE7 in 2007).
I see that most people seem to use Lame as their encoder but, if Pyro can't be used as an encoder.....then, I suppose Lame will be it.

Re:CPU Spike? (rickpaul)

Mon, 08 Feb 2010 12:32:52 GMT

If you're running 32-bit Windows, having 4 GB of RAM doesn't buy much more than having 3 GB of RAM, as 32-bit Windows actually only gives the system access to a relatively small amount over 3 GB, and, either way, SONAR (and any other applications) only get 2 GB of usable memory space apiece. However, it's conceivable that little bit of extra headroom was just enough to put you over some threshold you'd been hitting at the 3 GB level to avoid a lot of paging activity.

If you're that close, though, you may want to consider a future in the 64-bit world so you can get access to the full 4 GB of RAM (and beyond if/when that proves to be needed), and also so SONAR's memory space isn't limited to 2 GB. I recently upgraded from a 32-bit Windows XP Home system, running with 4 GB of RAM (but only a bit over 3 GB of that actually usable at the OS level) to a 64-bit Windows 7 Professional system, and things are way peppier. This is running on the same exact hardware, running the same version of SONAR. But it's not only SONAR that benefited. For example, my bootups and shutdowns are way, way faster, and the system performance in general is just snappier.

In my case, the 2 GB application space limitation for SONAR was a major bottleneck as I use a number of softsynths that have large memory spaces, and I was frequently having to freeze softsynths earlier than I'd have liked just to save on SONAR memory space. I know some guys who just use SONAR as a glorified tape recorder, mainly recording audio tracks, and you don't need a lot of RAM for that. When you start adding a bunch of large sample-based softsynths, though, your memory requirements can start to shoot up pretty quickly. Don't be fooled into thinking that just because someone you know can run SONAR well on a 2 GB system you should also be able to do that. You may be doing something very different from what they're doing. SONAR is a complex application that suits many different styles of usage, and those different styles can have a wide variety of resource needs.

Rick

Re:CPU Spike? (Wickens)

Mon, 08 Feb 2010 11:49:39 GMT

The memory issue is something I have as well.

I've been having tons of CPU spikes recently and I noticed on boot-up that my 6gb of DDR3 suddenly became 4.

I pulled out the bad stick, but I'm now running 4gb of DDR3 triple channel in essentially 2 channel mode which is totally mucking with Sonar when I'm doing anything.

Unfortunately because of apple, ram prices are through the roof right now too so I'm trying to find my old 3gb of DDR3 so I wont have this problem.

Re:CPU Spike? (Mesh)

Mon, 08 Feb 2010 11:36:51 GMT

Hi Rickpaul,
Although I thought the CPU spiking issue was solved after changing it to 24bit, it re-occurred the next day. In my posts, I forgot to mention that I used to have 4G's of ram when running SPE7, and 1gig got corrupted/went bad. I actually reformatted my HD before doing a fresh install of SPE8.5 with the 3G's.
Anyway, I replaced that 1G of ram last weekend and the CPU spiking was completely resolved. I checked this by playing/recording 10-15 audio tracks with softsynth and effects all running at the same time and no spiking at all!!!
I"m happy it's not my old soundcard causing this as I do like the GL824.

I just can't figure out why 3G's of ram would cause a CPU to spike to 100%? I see a lot of people running SPE8.5 on just 2G's.....so 3G's didn't occur to me as being a problem. Go figure!!
Maybe one of you guys can enlighten me on this?

Thanks again for all your advice, (I learned a lot more about my settings)
Mesh

Ps.
Rickpaul, you possibly misunderstood about my multiprocessor engine being turned off. I never turned that off as my processor is dual core and always had that box checked (even when doing all the other adjustments to find out the spiking problem).

Re:CPU Spike? (rickpaul)

Wed, 03 Feb 2010 02:29:40 GMT

Mesh, that's great to hear. I also recommend checking into the multiprocessor engine flag (from memory, I think it was in the advanced tab), as that may get you better performance when you start working on real projects (assuming it is compatible with your system, of course, but I think you said you had a dual core system, and the flag wouldn't even be available to check if you don't have a multicore or multiprocessor system).

Re:CPU Spike? (Mesh)

Tue, 02 Feb 2010 20:49:05 GMT

First of all RickPaul, I sincerely do appreciate the time you've taken to anlyze and reply to my CPU spiking problem. Cakewalk could certainly use your expertise & thoroughness!!
After reading your reply, you gave me options to check out and narrow the problem list.
I checked on your suggestion "First, in the general tab, you mentioned 16-bit for the bit depth setting. Most modern devices natively support 24-bit." I changed it to 24 bit and my issue was solved!!! I'm extremely happy that it wasn't a hardware issue.....thank you, thank you, thank you!!!!

I owe you one!!

Thanks again!!

Mesh

Re:CPU Spike? (rickpaul)

Tue, 02 Feb 2010 01:52:57 GMT

Hi Mesh, I read through your settings. While there are some that are different from mine, some are in hardware-dependent areas, and it may be that your device's characteristics cause the need for such differences. I'll mention a few of those anyway, though, just in case:

First, in the general tab, you mentioned 16-bit for the bit depth setting. Most modern devices natively support 24-bit. If yours does, it is conceivable that there is some extra work involved on both ends to ratchet the bit depth down and up. (There would be work to do on that anyway, since internal bit depth is 64-bit with your settings, but perhaps there is even more???)

On the ASIO settings and buffer settings, you've set some pretty high latency that would seem to me to be unusable for input monitoring, though fine for mixing and such. Normally, the lower you go on those settings (i.e. buffer size or latency, depending on how your audio card configures them -- I think you said it was number of samples in a buffer for yours), the more performance that is required from the system. However, in some cases, especially with some software instruments, I've seen there can be a threshold above which there are problems. You might try experimenting with that a bit more to see if anything, both at the extreme settings and in between, causes different performance.

The biggest question I'd have for you is how these settings compare to the settings that were working fine for you in SONAR 7. For example:

Were you using the 64-bit processing engine in SONAR 7? If not, try turning that off here, too, and see if that makes a difference. It does require more CPU power, and more memory.

Your I/O buffer settings at 512 are different from mine at 256. One would generally expect smaller I/O buffers to have more performance demands, but I have seen times in the past where I actually had to lower buffer settings to get past performance bottlenecks. The case I specifically remember was in a case of many audio tracks streaming off disk in parallel, where I'd get dropouts with higher settings, but, counterintuitively, lowering the settings let me get by. I rationalized this as my disk's not being able to keep up with a bunch of big requests in a possibly spiky fashion, whereas having more little requests perhaps got things serviced in time, even if it required more work.

I noted that you had Use Multiprocessing Engine turned off in the advanced tab, but you'd previously indicated you had a dual core processor. Unless you had specific problems that caused you to turn this off, I'd highly recommend turning it on, as you get more CPU power (not quite twice the power, but significantly more) from doing this. If this was different in your SONAR 7 setting, this could possibly explain this kind of difference in behavior in that everything would need to use the same core, and, if there is a bottleneck somewhere, something might get starved, whereas, in the case of using an extra core, if something is bottlenecked on one processor, there is another that may be able to service other needs.

This whole situation still seems very strange to me, especially when you indicated that a project that only had 2-3 audio tracks playing back was having this kind of spike. You don't indicate if there were any plug-ins on that, and which ones, if so -- perhaps some specific plug-ins have issues, though I'd think they'd have the same issues in SONAR 7 on the same system in such a case -- it's important to make sure you're comparing apples to apples.

One particularly curious comment I noted earlier in your responses read, "the CPU meter peaks at 100% with when arming a track and just playing a chord on my guitar.....when I stop playing, it levels down to 0%." This would suggest it is not just arming the track, but actually playing something through it, that is causing the spike (or at least serving as a catalyst for some issue). I've seen something of that sort in the distant past with some badly behaved softsynths (e.g. ones that had memory leaks), and that also makes me wonder if there is something about a plug-in you are using that could be involved. Again, it is important to make sure you are testing the same exact thing in SONAR 7 to qualify whether the issue is specific to SONAR 8.5, or if it's just a coincidence that something in there was used in 8.5 but not in 7 (at least not in the same way).

Another thing worth mentioning, and this also may relate to the multiprocessor engine setting: I've seen some plug-ins that have absolutely thrashed my system performance if their user interface was open while recording, but closing the interface (and not just minimizing it, but truly closing it) made things just fine. (The specific plug-in I'm thinking of at the moment has since been fixed as the problem was a bug in that plug-in, but I've seen less extreme cases with other plug-ins that simply have highly intensive user interfaces.) Here again, I'd expect the performance to be fairly similar on SONAR 7 and 8.5, but it's also the sort of thing that's worth trying (i.e. closing plug-in user interfaces when you get the problem) to see if it at least works around whatever the issue might be. This is an area where there may be less likely to be an issue with the multiprocessor engine enabled, but, at least in the worst case scenario I mentioned above, it didn't help enough.

One last thing I'll mention is that, when I see major spikes in CPU, one thing that tends to come to mind is if the system may be thrashing -- i.e. swapping memory areas out to disk to make room for other stuff that needs to be in memory, but then needing what was just swapped out and getting into a vicious cycle where more time is spent swapping things in and out of memory than doing meaningful work. You could check the Windows Task Manager's memory tab while this problem is happening to get a clue if this might be an issue here. I'd think your 3 GB of RAM would be way more than sufficient for a simple audio project, but the 2 GB of RAM (max) that SONAR gets to use in a 32-bit environment can sometimes not be enough for some softsynths that consume huge amounts of sample memory. It's also conceivable there could be other things going on with your system that come into play here, though, again, I'd expect behavior to be similar on SONAR 7 unless there is just a matter of having crossed a threshold that was near in SONAR 7, but not quite that near.

Bottom line is the most important thing to check is that you are talking about the exact same project, settings, and situation in the SONAR 7 and SONAR 8.5 cases to make sure it really is a difference in the two versions of SONAR, as opposed to just something that happens to be different between two projects, or with two different sets of SONAR settings, or when doing something different. But, if you do verify that the same exact situations get different results here, I think it is probably time to see if you can get some help from Cakewalk's support. I haven't seen such issues on SONAR 8.5 myself, but there could be something with your particular combination of ingredients that either finds some Achilles heel in SONAR 8.5 or where whatever performance-related differences SONAR 7 and SONAR 8.5 have provokes some other problem (e.g. with your Line6 stuff) that then affects SONAR's performance.
Good luck.

Rick

Re:CPU Spike? (Mesh)

Mon, 01 Feb 2010 12:06:11 GMT

Hi RickPaul and all,
I checked out the "Always Open All Devices" and it's unchecked. In that Advanced Tab, I have the following setup:

Playback I/O Buffer Size = 512 and Record I/O at 256
ASIO/Triangular
Use Multiprocessing Engine
Full Chase Clock

Everything else is unchecked or the default value of zero.

At the bottom of the Advanced Tab: Record Latencey Adjustment (samples)
My device is the Toneport ASIO DI-G 2in 1 out with the "Use ASIO Reported Latency:1211

In the Audio/Genral Tab, these are my settings:
Playback and Recording Timing Master: ASIO Toneport DI-G
Audio Driver Bit Depth: 16 with the 64 Bit Double Precision Engine being checked
The Sampling rate is at 44100

ASIO Reported Latencies:
Input 27.5 Msec, 1211 samples
Output 54.9Mse, 2422 samples
Total roundtrip 82.4 Msec, 3633 samples

After clicking on the ASIO Panel...button, it takes me to my Line6 ASIO Tone Port Driver device:
The Default Buffer size is 1024
Bit Depth 16Bit
I do have a Buffer Size slider that ranges from Extra Small to Extra Large. I moved it from the far left poition (Extra Small, as it was with Sonar 7.2x the default size) 2 notches to the right and hoping this would correct the CPU Spike. I then moved the slider to the middle (Medium setting) and just playing an audio track (as soon it hits the wave form, it spikes to 100% and fluctuates back & forth). It did the same thing when the Buffer Size slider was moved to the Extra Large side.

I also noticed that the CPU spike ONLY when a track is armed and/or with the Input Echo On, and when both are off, the CPU doesn't move from 00%.

I do appreciate all of your advice, and if you have any other suggestions I'm most definitely ready to try it!!
Thanks,
Mesh

Re:CPU Spike? (CJaysMusic)

Sun, 31 Jan 2010 23:07:58 GMT

No worries wintaper.

Re:CPU Spike? (wintaper)

Sun, 31 Jan 2010 22:50:24 GMT

He says Windows XP. There is no such thing as "Windows XP 32 bit". Its just "Windows XP". The "other" version is called "Windows XP x64 Edition".

I read it and the x64 version never crossed my mind. But I was somewhat kidding ,so sorry if I offended.

Re:CPU Spike? (badboogerfinger)

Sun, 31 Jan 2010 19:41:20 GMT

I too have been having issues with dropouts, scratch noises, pinging cpu meter.....ect. It started about 9months ago. I've had sonar 6, 7 and now 8pe. I have tried everything people have suggested. I have, I think, narrowed it down to my line 6 ux2 input device. Line 6 says its sonar(line 6 forums abound with this issue), and sonar techs have exhausted all their possible fixes. All I know is its impossible to record anything. Just moving my mouse fast caused a glitch. Sorry I am not offering a instant fix or an "aha" moment, just wanted to say, I feel your pain. In the end I will no doubt drop line6 and go to amplitube and not skimp on the input device. Good luck. Props to cakewalk support......they stuck in there. My next song will be "Line 6 can suck it."

Re:CPU Spike? (CJaysMusic)

Sun, 31 Jan 2010 13:00:48 GMT

Please learn to read posts before responding.

He didnt say it was a 32bit either. I guess you need to learn to read.
Cj

Re:CPU Spike? (wintaper)

Sun, 31 Jan 2010 12:11:53 GMT

Nowhere in the OP does it say he's running 64 bit XP. Please learn to read posts before responding. He's running XP on a x64 AMD CPU.

I think somebody's been spiking the 64bit punch " />

Re:CPU Spike? (CJaysMusic)

Sun, 31 Jan 2010 10:46:26 GMT

What was this about Cakewalk not supporting a card? Never hear of that unless you run Gigastudio. If an OS supports a card, so does Sonar.

Your confusing supporting and Recommended. If you read the help files. Sonar recommends certain types of sound cards
Can you show me ware me or anyone said his card was not supported by sonar. I dont take nicely when people put words in my mouth.

can't believe this started with assuming XP Pro is 64 bit. There is an XP Pro 64

Everyone i spoke to and friends with have XP pro and theirs is 64bit. I dont think it was that hard to get. I could have got it a year ago when building my pc. And the poster never stated was architecture he was using. I think the only knowledge you have is to put words in other users mouth's
Cj

Re:CPU Spike? (kitekrazy)

Sun, 31 Jan 2010 10:02:41 GMT

It appears some people lack knowledge of the different Microsoft OS. I can't believe this started with assuming XP Pro is 64 bit. There is an XP Pro 64, but very difficult to get these days and has even more limited driver support.

What was this about Cakewalk not supporting a card? Never hear of that unless you run Gigastudio. If an OS supports a card, so does Sonar.

You had Mesh confused there for awhile.

If you have any more issues you can check Black Viper's site on what XP services to disable.

Re:CPU Spike? (lorneyb2)

Sun, 31 Jan 2010 03:02:40 GMT

Just to clear up a misconception regarding XP Pro 64bit. Although they say it is no longer supported it does function well. I am using both 8.5 in 32bit and 64bit and it works well. Cakewalk just isn't testing it on an XP Pro 64bit platform so they will not provide assurance that it will work. The only significant issue I have had relating to the use of Pro 64 has been when installing from the DVD if there is an interruption in the install you have to start from scratch again, but I managed to get around the problem by using 7 Zip.

Re:CPU Spike? (rickpaul)

Sun, 31 Jan 2010 02:31:36 GMT

Mesh, I think it's safe to say this is not an issue of the wrong OS or the wrong audio hardware if all was working fine on SONAR 7. SONAR 8.5 should perform better, not worse, at least in my experience.

One possible clue here is that you upgraded from SONAR 7 to SONAR 8.5, not from SONAR 8 to SONAR 8.5. If you had the same problem upgrading from 8 to 8.5, that would be a real mystery. For 7 to 8.5, though, I've got one idea that I'd give decent odds of being involved.

My main suspicion is the "always open all devices" setting in the advanced audio options. This was added in SONAR 8 so people could arbitrarily decide to record on a device even after playback had started, whereas in SONAR 7 and below you had to arm your tracks before starting playback if you wanted to be able to record on that track later on. My understanding is having that capability active entails a potentially serious performance hit with some devices, so it's possible your device is one of those. Basically what happens, at least conceptually speaking, is, if you've got, for example, 8 audio devices (i.e. at the SONAR device level, not the number of audio cards level), instead of just having 8 devices open for playback if you're playing back a project, you'd get twice that number since all devices also have to be open for input in case you decide to arm one or more tracks on the fly. And each open device stakes out a little more CPU territory. Also, you mentioned using two different audio devices. If you are using WDM drivers, that could allow them both to be open (ASIO only allows one high-level device to be open at a time, but that could still have many sub-devices), with all sub-devices open, at the same time with this flag active. If that is it, you should try disabling that flag, and perhaps also deconfiguring any devices you aren't even using for playback (perhaps another difference between your SONAR 7 and 8.5 configurations?) to get a more apples-to-apples scenario.

You might also look into any other SONAR configuration changes you've made, or that got made for you in the case of not having SONAR migrate preferences (or preferences that didn't get automatically migrated), as something like a buffer size change could also make a significant difference in performance characteristics.
Please note that I don't generally read these forums, but someone flagged this post on the cakewalk.audio newsgroup, and I'd replied there, so I thought I'd share my thoughts here, as well.

Rick

Re:CPU Spike? (Mesh)

Sun, 31 Jan 2010 00:41:31 GMT

Of note...the CPU meter peaks at 100% with when arming a track and just playing a chord on my guitar.....when I stop playing, it levels down to 0%....
With all the negative feedback on getting a reply from Cakewalk tech support, I'm hoping one of you would be able to help me out?

Re:CPU Spike? (Mesh)

Sat, 30 Jan 2010 13:22:30 GMT

I know it's an old sound card, but the drivers are certainly compatible with 32bit systems and I could see your point being an issue if I were on the 64 bit platform.
I think I paid around $500 for the GL card before they closed shop...." />, but some of the engineers that worked for GL are still updating/modifying these drivers and do keep the unofficial site still running.
If Sonar 8.5.2 PE works on a 32bit system + my GL sound card's driver works on 32bit sys, shouldn't they work well together? (Since this is an out-of-date sound card, I realize cakewalk can't recommend it....but hardware-wise, they should be compatible....yes? no?).

Re:CPU Spike? (CJaysMusic)

Sat, 30 Jan 2010 12:37:31 GMT

I think its your old sound card (gadget lab sound card) and its very old outdated drivers. Im sure with a proper audio card that Cakewalk recommends you'll be on your way to sonar bliss. Your soundcard is not Recommended by Cakewalk.
Cj

Re:CPU Spike? (Mesh)

Sat, 30 Jan 2010 12:28:42 GMT

I verified my XP Pro is 32bit (I ran winmsd.exe and confirmed as x86 = 32bit). (http://support.microsoft.com/kb/827218)

CJ, I checked my audi.ini file and the threadsheduling is set at 1.
Even when I just playback an audio file with just a 2-3 recorded tracks, the CPU spikes to 100% Warning and it continuously fluctuates.

I also get dropouts when auditioning different loop files....(even after adjusting the latency).

I'm stumped!!

Re:CPU Spike? (John)

Fri, 29 Jan 2010 15:27:47 GMT

If you are running XP 32 bit it should not be a problem . CW still supports that version. By reading you first post I thought you were running XP 64 bit.

XP Pro came in both 32 bit and as a separate offering in 64 bits some time later. The way I understand it was the Pro version was the only version that came in 64 bits. There was only Home and Pro as types for that OS. The Pro version always came in 32 bits too.

Re:CPU Spike? (Mesh)

Fri, 29 Jan 2010 15:11:58 GMT

Thanks CJ, I'll check it out when I get home today. If it doesn't work, I'll have to convince the wife for Win7" />

Re:CPU Spike? (CJaysMusic)

Fri, 29 Jan 2010 15:00:44 GMT

I'm confused on "CW no longer supports XP 64 bits"....I have XP Pro and I thought it was running on the 32bit platform? (yes? no?)

XP64, is not supported. Is your XP pro architecture 64 or 86?? I thought XP pro comes in 64bit only. Im not sure though. It mau come in 32bit also

Of note, I didn't have these CPU fluctuations in Sonar 7.2xx as the meter was always around 2-10%).

Sonar 8.5 does not support XP64, so that may be part of your issue. In the requirments listed in 8.5 ,it stated that XP64 is not supported. Just Vsista64 and win7 64. 7.2 was supported by XP64.
You could try and change your threadsheduling to 1 or 2 in your aud.ini file. Im pretty sure 2 if for a quad core only. So try 1 first
Cj

Re:CPU Spike? (Mesh)

Fri, 29 Jan 2010 14:16:37 GMT

Hi John, I actually do have the 8.5.2 patch installed.
I'm confused on "CW no longer supports XP 64 bits"....I have XP Pro and I thought it was running on the 32bit platform? (yes? no?)

CJ, I do have an old Gadget Labs 824 ASIO soundcard, but I plug my guitar through a USB Toneport Gold DI box and use this as my In/output in Sonar.
I've also experimented with adjusting the latency (in Toneport), but the meters keep fluctuating.
I don't have anything running in the background when using Sonar as this is my dedcated DAW. (Of note, I didn't have these CPU fluctuations in Sonar 7.2xx as the meter was always around 2-10%).

Re:CPU Spike? (CJaysMusic)

Fri, 29 Jan 2010 13:52:55 GMT

Do you have an audio sound card?? Try raising the buffers. It could be driver related.
It could be that another program is causing it in the background. City could be a plethora of things. youll need to see whats running in your pc to figure it out. For starters you need to disable webcams, wireless and others until you isolate the problem child
Cj

Re:CPU Spike? (John)

Fri, 29 Jan 2010 13:49:55 GMT

CW no longer supports XP 64 bits. None the less I would run the 8.5.2 patch. Also there is a setting in the audio ini file that can improve CPU core balancing. That however is for quads and above. Here.

CPU Spike? (Mesh)

Fri, 29 Jan 2010 13:11:22 GMT

I just upgraded from SPE 7.x to SPE 8.5x and noticed that (after the new install) my CPU meter is always fluctuating and spiking to 100%. Is this normal and if not, what can I do to fix it?

I running an AMD Athlon Dual Core 64x2 5200 Brisbane(2.7 Ghz) processor on Win XP Pro with 3Gigs of Ram.