Pentium IV issues?

Hi all,

I’m getting a few complaints about my latest plugin having issues with the GUI when running on Pentium IV Windows machines (presumably they are all running XP). The audio is fine, but once the mouse enters into the plugin interface, the CPU shoots up to 99%.

Anyone have any ideas what might be going on here? My guess is that it is some compilation option in VS2010 that is not working well with the Juce code on the PIV. On my Core 2 Duo machines, things run fine, so I think that it is restricted to these older machines. I don’t have a Pentium IV XP machine for testing, so I’m just seeing if anyone here has run into similar problems in the past.


Sean Costello

maybe a denormal issue (pentium 4 has a really bad denormal performance), make a build with symbols, and use a profiler (like Very Sleepy or Intel Vtune)

Maybe you’re just doing a load of repainting each time the mouse moves?

Yeah, that sounds like the behavior of this bug - similar to an OSX issue I had a LONG time back. That’s what is weird, though - this isn’t showing up on any other platform (OSX/Intel, OSX/PPC, Windows/Core processors).

The issue seems to be GUI related - if the GUI is closed, the audio runs at a reasonable CPU consumption. Would there be denormalization issues in the GUI?

if it does many float calculations why not? (ok, maybe this is not the case), anyway using a profiler is always a good idea to see whats going wrong

and turn repaint debugging on, maybe there are many unnesscary repaints

The problem is that I don’t have a PIV to profile on. For Core2Duo and up, no problems.

OK, more information on this bug:

The guy testing my demo on his machine (Pentium® 4 2.53 GHz, 3 GIG ram, Windows XP SP3) reports that things now work smoothly, except for things slow way down when using the ComboBox or PopupMenu parts of my GUI. The actual text of the bug report:

[quote]CPU spike for 10-15 secs if I click preset menu. when it opens it is very sluggish to move mouse to preset. clicking the new arrows to change presets is fine though. same issue if i try to change the reverb mode.

Other things i noted, the plug-in takes a long time to load, maybe 6 secs that also spike the cpu, the GUI is blank for that time. Same thing if I hide and show the plug-in.

Also I was surprised to learn that this not limited to the DAW
If i open up another windows application with cubase still maximized, for example note pad. if that window hovers in front of the plug-in that is the background that will also spike the CPU even though cubase is disengaged including the sounddriver. Hope this helps. A vast improvement though.[/quote]

I am now compiling the plugin for 32-bit VST using VC2008. As I have mentioned above, I don’t have a Pentium IV for testing, and the code works well for me in XP and Win7 on my Core2Duo machines.

Sean Costello

Sounds like some kind of locking issue - does your plugin have to communicate between threads when the menu gets popped up, e.g. to build the items in it?

I only add to the menu items when a preset is saved, and saving the preset happens as one of the choices in the preset popup menu, which closes the menu. Otherwise, the menu items are stored in the editor class. So I don’t think this is the issue.

I have a possibly related bug report, this time on an Athlon:

[quote]I noticed there’s a weird issue going on with Valhallaroom and cubase…which I noticed in the previous version as well…(can’t remember if I noticed it with the first public version)…
The mouse becomes very sluggish when I point on a one of the GUI’s controllers (sliders or knobs)…until the text is shown in the buttom (the description of each knob/slider)…that also happens when I open the reverb mode menu…
the sluggish behavior is actually due to 100% cpu usage being made when I point my mouse over a controller until the text in the buttom is shown…
weird enough, that also happens with cubase 5…I tried the plugin with the free nice minihost and couldn’t reproduce that issue…
the valhallashimmer I also bought from you, does not introduce that issue with cubase…

my sys info: windows xp sp3, amd athlon64 3200+, nforce3 250gb chipset, 1GB ram, soundcard - RME fireface 400 with recent drivers, GPU - NVIDIA Gefource 6200, using cubase v5, also got UAD 1 card installed in…all my drivers in this old machine are recent.

It is worth noting that ValhallaShimmer (built in November of last year) doesn’t display this bug.

This actually sounds like the spin-lock issue mentioned on another thread today…

Pointers to the thread? A search on “spin-lock” turns up nothing.



I think I just bumped the “spin lock” thread, so hopefully this will expedite progress on this front. I have customers asking about these issues.

EDIT: looks like the change is in the source tree. I need to find a way to read RSS without Firefox opening up 300 tabs…

Sean Costello

or just open the summery, i do that everyday :wink:;a=summary


How did you fix it in the end? I ave the same problem with pentium 4 machines…

I did a build with the latest tip, but that did not solve the GUI problems only with pentium 4.


[quote=“Harrie Munnik”]Sean,

How did you fix it in the end? I ave the same problem with pentium 4 machines…

I did a build with the latest tip, but that did not solve the GUI problems only with pentium 4.

Hey Harrie,

The last time I built (check the date of the post), the tip fixed the issues. You also need to make sure that your optimization for the Juce library works with the graphics code. Set fp mode to precise, be careful with SSE2, don’t overly optimize the Juce code - in other words, enable the optimization flags for your DSP files and your audio processing plugin, not for the editor or the rest of Juce.

I need to put out a new ValhallaRoom build in the next few days, to make sure people have the latest fixes for the Juce code, and also to fix one of my audio bugs. I’ll check my VS2010 settings when I do so, and report back.


Thanks a lot Sean!