Mixxx 1.7.2 eats excessive CPU up to 100%

[jus]

Mixxx 1.7.2 / OSX 10.6.2 32Bit / MacbookPro5.5 Intel Core 2 Duo 2.26 GHz 4GB RAM / NVIDIA GeForce 9400M 256 MB

Mixxx v1.7.2 uses significant more CPU then v.1.7.2 on this configuration when waveform display in preferences = "Waveform".
Waveform display ="simple" does not work ( it does not work even in v.1.7.1 ).

CPU usage varies from skin to skin. The more waveform is shown, the more CPU is used.

Example:
Outline Skin ( no track loaded) : v1.7.1=15.4% v1.7.2=14.4%
Outline Skin ( 2 tracks loaded) : v1.7.1=17.7% v1.7.2=94.5%
Outline Skin ( 2 tracks playing) : v1.7.1=21.4% v1.7.2=100.5%

A full comparison for all skins is attached. Same as a time profile of Mixxx 1.7.2 running.

[jus (jus)]

Typo, it should read "...Mixxx v1.7.2 uses significant more CPU then v.1.7.1..."

[Albert Santoni (gamegod)]

What was your latency settings for each of these?

If you run Mixxx from the console, you should see some output about
"iFramesPerBuffer". You may want to compare those values between 1.7.1
and 1.7.2 because we changed the way the latency calculation works.
You may have been running at a higher latency than we quoted with
1.7.1 (for low latencies).

Thanks,
Albert

On Tue, Jan 5, 2010 at 11:51 AM, jus <email address hidden> wrote:
> ** Tags added: skin
>
> --
> Mixxx 1.7.2 eats excessive CPU up to 100%
> https://bugs.launchpad.net/bugs/503435
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[jus (jus)]

v.1.7.2 using default latency settings = 92 ms
iFramesPerBuffer=8192

v.1.7.1 using custom latency settings = 100 ms ( uups, haven`t checked that lately)
There is no iFramesPerBuffer entry in Console, maybe iLatencySamples?
iLatencySamples=8820

CPU Usage after changing each version to 3 ms latency:
Outline Skin ( no track loaded) : v1.7.1=22.5% v1.7.2=20.4%
Outline Skin ( 2 tracks loaded) : v1.7.1=25.0% v1.7.2=94.2%
Outline Skin ( 2 tracks playing) : v1.7.1=39.0% v1.7.2=98.5%

iLatencySamples after changing to 3 ms latency
v.1.7.1 = 264

iFramesPerBuffer after changing to 3 ms latency
v.1.7.2 = 256

[Albert Santoni (gamegod)]

Hi jus,

Thanks for the additional data.

When you have a chance, can you compare the CPU usage of 1.7.1 at 3ms
to the CPU usage of 1.7.2 at 6ms?

I think CoreAudio might be doing some sneaky stuff to effectively
round up the 264 samples/period to 512, which would make 1.7.1 run as
if it were at 6 ms latency, even though the latency slider in Mixxx
was set to 3 ms.

Thanks,
Albert

On Tue, Jan 5, 2010 at 1:14 PM, jus <email address hidden> wrote:
> v.1.7.2 using default latency settings = 92 ms
> iFramesPerBuffer=8192
>
> v.1.7.1 using custom latency settings = 100 ms ( uups, haven`t checked that lately)
> There is no iFramesPerBuffer entry in Console, maybe iLatencySamples?
> iLatencySamples=8820
>
>
> CPU Usage after changing each version to 3 ms latency:
> Outline Skin ( no track loaded) : v1.7.1=22.5% v1.7.2=20.4%
> Outline Skin ( 2 tracks loaded) : v1.7.1=25.0% v1.7.2=94.2%
> Outline Skin ( 2 tracks playing) : v1.7.1=39.0% v1.7.2=98.5%
>
> iLatencySamples after changing to 3 ms latency
> v.1.7.1 = 264
>
> iFramesPerBuffer after changing to 3 ms latency
> v.1.7.2 = 256
>
> --
> Mixxx 1.7.2 eats excessive CPU up to 100%
> https://bugs.launchpad.net/bugs/503435
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[jus (jus)]

Mixxx 1.7.1 : Latency is continuously variable between 2-16ms, then in bigger steps up to 400 ms.
Mixxx 1.7.2 : Latency can only set to 1,2,5,11,23,46,92 or 185ms ( same as in current trunk r2255).

I can`t set the v1.71 latency to double the value of v1.7.2.

[Albert Santoni (gamegod)]

jus: If you have an OS X build environment set up for Mixxx, you may want to compare Qt 4.5.3 performance vs. Qt 4.6. I believe some OpenGL painting stuff has changed in 4.6, and maybe this could be where these performance problems are coming from. The effect of changing the skin on performance is a hint that this might be the problem.

RJ and I stared at your Shark Profiler output today for a while, and neither of us see anything that jumps out as out of the ordinary.

[jus (jus)]

Since this bug really annoys me ( it is also in the current 1.8 branch) i made once again a comparison and found that some code change (1.7.1->1.7.2) regarding the Pitch sliders may be the root of the problem.

*Mixxx` 1.72 preferences set "Pitch/Rate Slider range" to 90%
*Drop Song to Player 1--> CPU peaks at 100% permanent
*Change slider to -90%-->CPU drops to 1/4 permanent

If the song is playing we have the same effect.

Screencap
http://dl.dropbox.com/u/3077984/MixxxR172_osx_cpu_hog_bug503435.mp4

[Albert Santoni (gamegod)]

Hey Jus, that screencap you posted is very interesting.

I think it's telling us that whatever part of Mixxx is doing more work as the pitch slider is increased is making a significant contribution to the CPU usage. This isn't something that's occurred to me before.

Off the top of my head, the most obvious pieces of code that this could be are the time stretching code (pitch independent vs. vinyl emulation) or the MP3 decoding/reader code. However, the waveform renderer could also be doing "more work" as you increase the pitch slider.

When you have time, can you please set the waveform to "simple", and repeat the pitch slider experiment to see if the CPU scales in a similar way?

I think that will tell us a lot...

Thanks,
Albert

[jus (jus)]

Same problem as seen in the screencap is on the current 1.8b2 r2363.

Setting the waveform to simple - and the CPU usage goes back to normal.
Constant low around 15-20%, even when using the pitch slider.

[Albert Santoni (gamegod)]

On Thu, Mar 11, 2010 at 12:50 PM, jus <email address hidden> wrote:
> Same problem as seen in the screencap is on the current 1.8b2 r2363.
>
> Setting the waveform to simple - and the CPU usage goes back to normal.
> Constant low around 15-20%, even when using the pitch slider.
>

Ok, thank you very much for the feedback!

I think this strongly suggests that the waveform rendering is causing
the increased CPU usage. We'll investigate this further...

Thanks again,
Albert

[hiend (hippako)]

Same here on Ubuntu Lucid, So I disable the waveforms and everything back to normal 20-30 % of CPU. Then I try to enable back and I get corrupted picture (attached below). I'm using Ubuntu Lucid with default nouveau driver without compiz.
Laptop: Intel 2.0 Ghz, 2gb RAM, nvidia GT7300.

[Sean M. Pappalardo (pegasus-renegadetech)]

What version of Qt was used in the 1.7.2 OSX package?

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5272