[linux-audio-user] CPU clock - beware - Solved for now?

Malcolm Baldridge linux-audio at paypc.com
Wed Jul 21 22:29:39 EDT 2004

> Thanks to everyone who responded.  My friend Kevin Ernste pointed me to
> one of many forum threads which talk about using "noapic nolapic" (hey,
> that's a good rhyme!) as kernel arguments for the nforce2 chipset.  Like
> this one:

How bizarre that L-APIC is broken on that motherboard.  Local-APICs are
usually on the CPU itself... Even if a motherboard as a real IO-APIC, often
it's setup and wired so badly or the BIOS misconfigures it such that it's

> I did that early this morning (actually, I just passed nolapic so far),
> and have not had a single problem at the normal clock speed, throwing
> everything I could at it.  I had qjackctl open running alsaplayer into a
> simple jack-rack amplifier into freqtweak into a rezound record, while
> burning a CD, encoding an mp3, and playing with Celestia.  

> Aside from
> Celestia and the mp3 encoder being fairly slow and the cpu temp reaching
> 41C during that episode, everything seems pretty solid.

Your mp3 encoder is probably built "lamely".  An Athlon-XP runs optimally
with '-mcpu=athlon-xp -march=athlon-xp -O2 -fomit-frame-pointer -s'.

When you build your mp3 encoder, try defining CFLAGS and CXXFLAGS prior to
the configure invocation, such as:

(note, there's nothing after each \ except the carriage return)

CFLAGS='-mcpu=athlon-xp -march=athlon-xp -O2 -fomit-frame-pointer -s' \
CXXFLAGS='-mcpu=athlon-xp -march=athlon-xp -O2 -fomit-frame-pointer -s' \
LDFLAGS=-s ./configure --blah --blah --blah

If you're using an old GCC, then replace the 'athlon-xp's with
'pentium-mmx', or if it's REALLY old, just 'pentium'.  The default is really
piss-poor ia386 code.  Distros still build for 386 or 486 processors to
provide "universal support", and for most things, the difference isn't big
enough to get too cranky about it.  But for things like mp3/mpeg-2 encoding,
the difference is remarkable.  

I suggest you get a modern GCC compiler (3.3.4 seems safe enough, 3.4
introduced some weirdness which broke some builds of mine that were
functional for years).

An encoder like LAME has flags for some optimisations as well - go ahead and
enable them. 

You should get ferocious encoding speeds with anything modern.  For a 2GHz
machine, expect at least 8X real-time encoding speeds.

A focus on Quality.

More information about the Linux-audio-user mailing list