So, try this on for size: Empeg Mark III with crusoe processor and a color display?

Hey, it'd give you an excuse to work directly with Linus Torvalds.


-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

Well, the Crusoe is pretty darn good for an x86, but compared to the StrongARM, it's very power-hungry and doesn't have any on-board I/O. Not really ready for embedded apps yet...

Hugo

Just as a curious aside...

My understanding is that the StrongARM has very low power consumption in part to its lack of floating point unit. This makes perfect sense for most of the Empeg's (discrete) operations, like organizing playlists and playing music, but doesn't it present a special challenge for the third-party company that develops your on-screen visuals?

Corby
SN#320, 6-Gig Blue

There are in fact ARMs with FPU's - and these aren't hugely power-hungry chips either. FP is not required for most operations - MP3 decode is generally a FP intensive task on an x86, but a suitable integer decoder (such as run by the empeg) gives the same output and takes much less CPU time by using fixed point arithmetic.

The StrongARM has a very fast (1-3 cycles) 32x32->64 bit multiply/multiple accumulate, which makes signal processing applications just fly :)

Prolux have always worked with the ARM, so the lack of FP has never been an issue. Most of the graphics are based around FFTs of the data - again something which can be well optimised for integer CPUs - the rest is usually some fast plotting :)

Hugo

Firstly, just how power-hungry is the Crusoe anyway? I thought it was 1 watt at standard operation? What's the stats on the StrongARM in comparison?

Secondly, the way I understood the MP3 format was that the spectrum graph (i.e. what the FFT produces) was pretty much available with minimal transformation from the actual MPEG information. If that was available, surely a lot of the frequency data could be used in the visualisations with little cost? Can someone who knows more about the actual format tell me whether this is wrong or right?

Incidentally, I see someone has come up with a way to do FFT-like operations using a very small number of multiplies and shifts; it works something like ten to fifty times faster than the best FFT algorithm and is only marginally more inaccurate (the best is something like 8.92Db vs 8.86Db THD or something). I don't know the link, but it was mentioned on Slashdot.

Who knows what these scientists can come up with?

Save the whales. Feed the hungry. Free the mallocs.

The Crusoe is 1.4W when playing MP3s. The SA, in the high-power app we use it in, is <0.45W flat out, and at 190Mhz is <0.2W flat out - for MP3 playing, make that 0.15W and 0.09W-ish.

The MP3 bands are a bit limited for using for visuals, we just do a FFT. The visuals rarely take more than 2% of CPU time, including FFT and drawing the visual 38 times a second.

Hugo