Talked to one of the Rio engineers and got a few corrections and additions to the technical data.
– The CPU is the 5003, not the 5002. The 5003 has a better cache architecture and some other improvements (and an ethernet MAC onboard).
– USB onboard the 5003 is not used, as this is USB1, 12MBit. There’s a Cypress controller doing the USB2 480Mbit.
– The RAM usage is actually more buffer than workspace/code/fonts/etc. We don’t use the Hitachi’s APM features, we just turn it off – the APM stuff isn’t low power enough. I’m not aware of any HDD jukebox which relies on the HDD sleep modes, as they’re not (yet) zero power on any HDD. The RAM is low power Micron mobile SDRAM.
– The onboard database isn’t much like the empeg-car’s one, nor like the Rio Central database that came after it. It’s a DB specially optimised for the Karma’s needs.
– Power output is max of 55mW/channel (into 16 ohms), not 55W. That’d be kinda painful ;)
– The parametric EQ feature is more from the car player (which actually had a separate DSP that did it, but it convinced us of the merits of fully parametric EQ)
He also mentioned an interesting thing about Ogg decoding on the Karma:
Karma (along with other embedded OGG players like the Neuros) use an integerised version of OGG which requires no floating point operations – much the same way as the MP3 and WMA codecs are also integerised versions of code that, in its first form, required floating point support (software or hardware) to work.
When I say “integerised” (nice new verb, eh?) I mean someone has gone through the code and worked out how to implement each part in fixed point without significant loss of accuracy – ie, the output is generally +/- 1 LSB when compared to a reference implementation.
On a side-note, if you’re looking to get scratches out of the faceplate (including those annoying buff-marks that come on it out of the box), I’ve tried Novus polish, and it works like a charm.