I have to agree with cjdshaw. There's something else going on besides CPU utilization.
As I reported in one of the beta threads, with more than 1 CPU running, the analyze function actually gets corrupted when something is playing at the same time.
I just ran a test...
With my server configured for 1 CPU (a 1.8Ghz XEON), playing an MP3 track causes my CPU utilization to twitch 10-15% at the start of the track and 2-3% every 10-15 seconds or so, but remains literaly 0% throughout the rest of the playback. If I stop the playback and analyze a track, it spins the CPU at 100% and analyzes at about a 40X rate. If all threads have the same priority, then it's POSSILE that the playback thread is suffering, but adding CPUs should make the problem get BETTER, not get worse.
Unless... some common code module is not thread-safe. In fact, one of the classic symptoms of a non-thread-safe code is that the symptoms get worse as you add parallel CPUs.
To support this theory, I started a track playing, then attempted to convert another MP3 track to a different bitrate. During the "decoding" phase of the convert, I got the same "skips" but during the encoding phase, which also ran the CPU at 100%, the playback was perfect. The skips were present in the final converted track! So, I then enabled the other processesors and attempted to play and convert again and... the decoder phase only decodes the first few seconds of the track and then encodes it into garbage which is the same behaviour as analyze.
So, I think you have a real problem with multiple uses of the MP3 decoder at the same time.
Remy
P.S. I've never tried to analyze/convert and play the same track at the same time. I know that's not going to work.