MuTools

snooty30 · Post by **snooty30** » Sun Jun 18, 2006 2:38 pm

Hello

Don't know if this is the right forum to ask (I can't get on the Computer Music forum at work!) but I just upgraded to P4 CPU & the CPU bar is maxed out. I remember reading something about this somewhere but can't seem to find it.

Can anyone refresh my memory?

mellotronaut · Post by **mellotronaut** » Sun Jun 18, 2006 2:56 pm

Ding dong!
I bought a new pc three weeks ago, pentium double processor 2.8 and I have exactly the same problem. I used a 4 years old p 4 before and no problem.
I wanted to remaster my old cmuzys stuff....Somebody knows, what to do?

> DiGiT < · Post by **> DiGiT <** » Sun Jun 18, 2006 4:10 pm

its a denormal issue most likely, and can be remedied with this:

mellotronaut · Post by **mellotronaut** » Sun Jun 18, 2006 4:14 pm

Thanks a lot, digit! I'll try it out.

It's the second time you save me!

Mello

> DiGiT < · Post by **> DiGiT <** » Sun Jun 18, 2006 6:02 pm

so hows the music these days?

muzycian · Post by **muzycian** » Mon Jun 19, 2006 9:05 pm

You say "the cpu meter is maxed out".

But is it only a graphical issue, and does the music plays fine, without hickups?

I remember about such (graphical) issue with (C)Muzys.

james0tucson · Post by **james0tucson** » Mon Jun 19, 2006 9:44 pm

muzycian wrote:You say "the cpu meter is maxed out".

But is it only a graphical issue, and does the music plays fine, without hickups?

I remember about such (graphical) issue with (C)Muzys.

It sounds like the problem of low signals going into the floating point denormal territory.

The problem is fairly hard to explain if you are not familiar with how floating point numbers are represented in the computer, but basically, it's that really small numbers (close to zero) are handled differently from the main part of the floating point range. (The "infinities" and "NaN" are also handled specially, but we don't tend to run into those.)

The main things to understand about floating point, are that the base number is usually "normalized" so that the first digit is "1" (binary). You can always shift the base to do this, and when you do, you gain an extra bit (because it's normalized, you can drop this first bit and the exponent compensates for the shift.)

But when you get numbers really close to zero, you lose some continuity of precision. This is compensated for by dropping the leading "1" which gives more accuracy, and using zero for the exponent (which can be interpreted as an exception by the floating point processor), and the benefit is that we end up with *much* more continuous precision close to zero.

We're talking about numbers on the order of magnitude of 2^-324 to 2^-308 in single precsision; this is really small. If an audio processor tries to deal with numbers in this range (I suppose a long reverb tail gets there), the FPU will go into a mode where it's processing exceptions instead of the optimized datapath for "normal" floats.

I'm sure it's frustrating and ironic that the least significant data would incur the largest processor cost, but then if you were to ask the scientific computing world whether we should do away with support for denormal floats, they'd balk at the idea. It turns out that there are fields where the numbers really close to zero are important -- and they also need to be in the system that includes big numbers...

Sorry I don't have a solution to offer. I guess it's a tough call; if you have to put conditionals in your code to check if numbers are getting below a threshold, you introduce a performance hit that might be worse than the denormal processing. The usual fix is to put noise into the signal -- it's noise, but it's so vanishingly far below any meaningful noise floor for audio that it is acceptable.

> DiGiT < · Post by **> DiGiT <** » Tue Jun 20, 2006 3:57 pm

thanks. uh... you can fix it with the plugin mentioned above.

james0tucson · Post by **james0tucson** » Tue Jun 20, 2006 4:08 pm

> DiGiT < wrote:thanks. uh... you can fix it with the plugin mentioned above.

You can hide the problem for the specific case where you can put that plugin in the datapath, but I think people should also understand the nature of the problem.

snooty30 · Post by **snooty30** » Tue Jun 20, 2006 4:17 pm

It IS just a graphical thing but it's nice to know how much CPU power left I have to play with. Does it matter where the plug in goes in the signal path?

muzycian · Post by **muzycian** » Wed Jun 21, 2006 8:36 pm

No, i think it doesn't matter. I think (C)Muzys' cpu meter algorithm is not working properly on all systems. I'm not sure... it's not supported anymore.

Did you try LUNA already?

snooty30 · Post by **snooty30** » Mon Jul 31, 2006 7:53 pm

muzycian wrote:No, i think it doesn't matter. I think (C)Muzys' cpu meter algorithm is not working properly on all systems. I'm not sure... it's not supported anymore.

Did you try LUNA already?

Yeah I tried Luna. Not for a while though. Couldn't get a flow going with it but will try again.

muzycian · Post by **muzycian** » Mon Jul 31, 2006 8:18 pm

snooty30 wrote:
muzycian wrote:No, i think it doesn't matter. I think (C)Muzys' cpu meter algorithm is not working properly on all systems. I'm not sure... it's not supported anymore.

Did you try LUNA already?
Yeah I tried Luna. Not for a while though. Couldn't get a flow going with it but will try again.

Well, i'm always interested in why something isn't obvious, so please let me know what you didn't find obvious.

What's your 1-2-3 to rock'n roll on a computer?

I really want to make LUNA super easy

MuTools

KVR Audio

CMuzys CPU bar on P4