iPod May Not Have The Horsepower For Ogg [updated]

An anonymous reader writes "Gizmodo has an interview with a Rio engineer who speculates that current iPods may not have enough CPU power and/or memory to decode Ogg. He concludes that the Minis might be able to do it, and the next generation iPods will certainly be able to. Of course, just because Apple can doesn't mean it will." Update: 06/06 04:44 GMT by T : csm writes with this rebuttal: "According to Monty from Xiph.org (author of the Tremor codec and OGG itself), it should very well be possible to run Ogg on older generation iPods."

Comments

The name is wrong

[iriefrank]

Not to be a smartass, but Ogg is just the name of the larger project. The actual audio compression format is called "Vorbis."

Re:No call for......

[tuffy]

Does OOG have much more memory requirements than other formats ? If so, why ?

Vorbis is a better codec at sticking more audio data in less space due to the years of research between itself and MPEG-1. But decoding that data doesn't come for free, and so Vorbis decoding is more memory and CPU intensive than mp3 is. But thanks to the integer decoder, that difference mainly shows up in high bitrate Vorbis files.

Re:Apple will not

[mindstrm]

AAC and MP3 do not have DRM either.. the DRM layer was added for the iTunes music STORE, which is a recent addition.... people bought ipods LONG before the iTMS existed.....

Why do people insist on thinking that ipods and itunes are all just about the store? The majority of ipod owners DONT use the store.

mild Gizmodo rebuttal from Monty

[xiphmont]

I sent a mild rebuttal to Gizmodo about Hugo's article back when Gizmodo first ran it. As it hasn't appeared on Gizmodo, here's the text:

Hi there; it's interesting to see one's software being talked about by others as if it fell from the sky :-)

First off, the original iPod does indeed have the horsepower for Ogg; the original Tremor codec written in C used approximately 40MHz of a Cirrus Maverick (720TDMI), an ARM7 chip somewhat more underpowered than the chip in the iPod. What the Maverick often has that many other DSPs don't have is access to alot of memory. This was indeed a stumbling block for a while.

Since then, we've made three mostly seperate branches of the Tremor codec line (used in the Rio), each tailored to specific CPU and memory structural differences found in different DSP architectures. Hugo Fiennes didn't mention which he was using... or if he was aware there are multiple different branches today (although I expect he is aware, it's worth mentioning).

From the story:

"The 5002 has a "broken" cache (1 wait state per access for program or data, meaning you effectively have half the effective clock rate when running code from external memory). This means that running code that doesn't fit in the internal 96kbyte SRAM of the player is very inefficient, both in terms of CPU cycles and power."

He didn't say if he meant code, data or both, but modern Tremor can fit both comfortably into this space. This is still substantially faster than the ARM7 DRAM-based access Tremor was originally designed for (using SRAM as a random-replacement cache with 7-14 wait-states on a cache miss).

Also, he says it uses more power but also says they didn't optimize much and so, they're mostly using the stock ANSI C Tremor decoder, written by a single engineer (me) in a month as a 'starting point' to help other engineers write a Vorbis decoder for their own platforms. The mp3 playback is likely handcoded assembly written by a professional team focused on only that task. This is in fact astounding! It's also a testement to the power of good modern compilers. I smile every time GCC soundly beats me at optimizing.

I agree that the newer iPods are more likely to decode Ogg and Vorbis with ease. I do, however, strongly believe the original iPods can also do so with room and cycles to spare.

Monty
TD, Xiph.Org

Re:Huh?

[busonerd]

Speaking as a member of the ipodlinux project, there is a lot of room for optimization. 80% of realtime refers to running a decoder and linux on only 1 of the two cores ( the other is only running a dma-engine) currently. One of the next big tasks is to put both cores to work (for technical reasons, smp is most likely impossible).

As well, the story is wrong about storing their code in flash. Only the bootloader is stored in flash, which bootstraps the os from the harddrive into sdram, so flash or not, its a non-issue.

--David Carne

Re:RTFA, though you probably won't understand it

[pchan-]

So unless you're just another ignorant Apple fanboy, refute the guy's arguments.

okay, i will refute the guy's arguments. i am an embedded systems developer, and often deal with swapping code in from dram/flash to sram for quick execution just such as this. the guy's arguments are, well...

The 5002 has a "broken" cache (1 wait state per access for program or data, meaning you effectively have half the effective clock rate when running code from external memory). This means that running code that doesn't fit in the internal 96kbyte SRAM of the player is very inefficient, both in terms of CPU cycles and power. MP3 and AAC just about squeeze into the internal memory (one at a time, obviously!), but anything that didn't would result in a big power hit - my guess is 30-40%+. This would be a bad user experience, considering the already short gen3 battery life.

first, the cache is not broken. this is a common design limitation of embedded processors. running code or accessing data from external ram can be VERY slow (1 cycle delay is pretty good). however, his argument is bullshit. the support code for the codec is usually run from dram (like the "open a file, parse a bitstream part"). the core decoder loop, on the other hand, is loaded into sram for fast execution (code and data). if the ogg vorbis decoder can be squeezed into whatever apple has left of the 96kb depends mostly on the efficiency of apple's memory allocation. but i have no doubt that they could do it (they may need to optimize some tables out by computing them at runtime, and other such tricks).

having said that... adding a complex codec into such a system such as the ipod firmware is a major pain in the ass. they may want to enable vorbis support, but it is a large amount of work, and probably hard for apple engineers to justify. if someone could find a good excuse for apple marketing to justify it, i'm sure engineering could figure it out.