[vorbis-dev] How many MIPS for Vorbis Decoder?

[John Ripley]

> From: Dan Conti [mailto:dconti at acm.wwu.edu]
> Sent: 20 March 2004 02:47
> To: vorbis-dev at xiph.org
> Subject: RE: [vorbis-dev] How many MIPS for Vorbis Decoder?
...
> > From: owner-vorbis-dev at xiph.org [mailto:owner-vorbis-dev at xiph.org]On
> > Behalf Of John Ripley
> > Sent: Friday, March 19, 2004 4:51 PM
> > To: vorbis-dev at xiph.org
> > Subject: Re: [vorbis-dev] How many MIPS for Vorbis Decoder?
> >
> > The 7312 is a fantastic embedded CPU, but it's quite dated, 
> and 48KB is
> > way too little RAM. I believe the internal SRAM on the 
> Cirrus 7312 is
> > also half speed, and very many cycles to access. I ran some 
> benchmarks
> > on it a while back and discovered to my horror that it was about 5
> > cycles random access and 2-3 cycles sequential depending on 
> core clock
> > speed. It wasn't actually worth the programming effort to 
> put anything
> > in internal RAM because cache was way faster, and internal 
> vs external
> > made very little difference to power consumption or performance.
> 
> There are AAC, WMA, and MP3 libraries available that require 
> less than 24K
> of ram; i was able to get each of these running on the 
> on-chip ram on that
> processor. Along with a relatively full fat filesystem, audio 
> buffering,
> simple UI, etc. For that part, SRAM is actually a saving 
> grace, since random
> access to sram is about half as many cycles as random access 
> to sdram, but still, it's not an ideal setup in many ways.

AAC, WMA and MP3 manage that 24KB footprint usually because they keep their
codebooks in ROM, or have some overlay system that pages the appropriate
book on demand per file, and the advertising doesn't count ROM space. You
can't do that with Vorbis because the codebooks aren't fixed. This is even
more unfortunate because you can't "compress" the working tables at compile
time. On platforms with flash that the CPU can't automatically page (NAND),
demand paging of tables can't be done real time, or at the very least not
easily.

> Do people really put more than ~50K of sram on chip these 
> days? Guess i'm out of the loop :)

50KB ram is so last century, I think even some PICs have more than that now
:)

...
> I just noticed you work at rio. I thought you guys switched 
> to the 7312 for
> most of your stuff? Maybe that was just a few of the 
> handhelds. And that rio boombox product that never came to be :)

For the flash players (and Nitrus) it's a Sigmatel 3410, which is basically
a souped up Motorola 56k with 288KB RAM. The Karma has a PortalPlayer 5003
in it - two ARM7TDMI cores and 16MB SDRAM. The 7312 stopped being useful
because it lacks the peripherals we need.

> I agree though, in general, if you have a complex UI to 
> support it's going
> to be difficult to fit it in a small memory footprint. Also i 
> dont really know how much ram tremor wants these days.

Both Tremor-lowmem (last I checked) and my own little decoder take in the
ball park of 128KB RAM (x86 code and data, similar on ARM).

> > I think over the next year we may see a lot of "MP3" player 
> chips which
> > have plenty of internal RAM, e.g 256KB+. Embedded DRAM 
> (refreshed 1T)
> > seems to be the next big thing. Makes my life easier anyway :)
> 
> I really doubt it. The success of the ipod mini throws the 
> whole flash based
> player market into question. Why would chip manufacturers add 
> more on chip
> ram, which results in significantly more expensive parts, 
> when people are
> buying HD based products which have off-chip memory for buffering?

I think you're severely underestimating the cost and power consumption of
off-chip memory. The flash market does exist for a reason, despite Apple's
reality distortion field.

- John Ripley.
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.