CPU1 lazy while CPU2 rips

[Cugel]

Hi,

I have noticed the following on the latest version of DbPoweramp Reference (R12.4): While one track is ripping and CPU1 is encoding another track to LAME, CPU1 basically grinds to a halt – it manages to encode a few percent at most. On the other hand, if CPU2 is doing the encoding (to Lame) it happily encodes at good speed while another track is ripping. What's up with that?

It is a little annoying, because what happens is that the ripping stops periodically because the lazy CPU1 only starts doing its job when CPU2 also is encoding.

In a review at CNet, they have observed something along the same lines:

Funny thing I observed though: when ripping CD's with dBPowerAmp 12 (which uses both CPU cores separately, to rip two songs at the same time), I've noticed a discrepancy between the speed of CPU1 and that of CPU2, with the former being outrun by the latter...
Strange, indeed

.

Same problem?

[Edit: Posted to the wrong Forum. Sorry! Can't find a way to move the post over to the right forum]

[LtData]

Re: CPU1 lazy while CPU2 rips

Moved to the CD ripper section of the forum
Now, what CPU and version of Windows are you using?

[Cugel]

Re: CPU1 lazy while CPU2 rips

Now, what CPU and version of Windows are you using?

Windows XP Professional Version 2002 Service Pack 2 on a Fujitsu Siemens Esprimo with "Intel(R) Pentium(R) 4 CPU 3.20GhZ 2.78 GHz, 1,50 GB RAM. PAE (Physical Address Extension)".

[LtData]

Re: CPU1 lazy while CPU2 rips

Your "two" CPU cores is just a P4 with Hyperthreading, which uses a virtual core, which would probably explain why one CPU is fast and the other bogs down.

[ComeUpon]

Re: CPU1 lazy while CPU2 rips

I'd like to point out that I've noticed the same thing when ripping CDs.

I'm running XP SP2 just like Cugel, but my CPU is an AMD X2 3800+, not a P4.

I always kind of assumed it was normal--it just never really bothered me.

[LtData]

Re: CPU1 lazy while CPU2 rips

Then it sems like the problem is not directly related to the fact that the OP is using a hyperthreaded CPU after all. This seems like something Spoon would have to look at.

[Spoon]

Re: CPU1 lazy while CPU2 rips

Sometimes the % counter for CPU can stop, but the encoding is still going on in the background, the reason it stops is the CD Ripper ripping thread has a higher priority than the encoding. It is like the encoders which seem to stop at 100% and wait, they are not waiting as encoding has finished, just the display (GUI) has not picked it up.

[pls1]

Re: CPU1 lazy while CPU2 rips

If you want to visually monitor your CPU performance, I recommend Process Explorer from Sysinternals (now Purchased by Microsoft). It's a free tool that is similiar to task manager but with better granularity.

http://www.sysinternals.com

Phil

[bhoar]

Re: CPU1 lazy while CPU2 rips

I concur with Phil. Much more useful than the task manager of most in-program monitoring.

-brendan

[Cugel]

Re: CPU1 lazy while CPU2 rips

Sometimes the % counter for CPU can stop, but the encoding is still going on in the background, the reason it stops is the CD Ripper ripping thread has a higher priority than the encoding. It is like the encoders which seem to stop at 100% and wait, they are not waiting as encoding has finished, just the display (GUI) has not picked it up.

I have noticed GUI lag before but when the GUI lag stops, the percent figure jumps rapidly up to a higher number.

In this case it does not. It just sits there at for example 15% until the other processor finishes ripping and then it gets going at 16%. What's more – it is always CPU1 that waits for CPU2. Never the other way around which sort of speaks against GUI lag.

And when CPU1 is ripping CPU2 always encodes away at good speed.

ComeUpon, do you have GUI lag or a lazy CPU?