Hi all, Does anyone have any experience porting libvorbis to platforms with small total memory sizes? Specifically, I'm trying to figure out if it's feasible to run Ogg Vorbis decoding on one of the PlayStation 3's SPU's -- secondary processors with only 256kb of local memory. It looks like out of the box the memory footprint of libvorbis is roughly: ~130k code ~60k static data ~160k heap So clearly there's some work to be done. I have some ideas of things to try... speed isn't a huge issue so I could eliminate some of the lookup tables (e.g. for mdct and windowing), and I could try to tease apart the analysis/synthesis code, as it looks like a lot of code on the analysis side is needlessly being linked in. But, before I dive into that I was wondering if anyone has any experience with this sort of thing and could give me some idea of how much work it's likely to be. Thanks, -Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20070308/4d83fb61/attachment.htm
On 3/8/07, Ethan Fenn <ethan@harmonixmusic.com> wrote:> > > Hi all, > > Does anyone have any experience porting libvorbis to platforms with small > total memory sizes? Specifically, I'm trying to figure out if it's feasible > to run Ogg Vorbis decoding on one of the PlayStation 3's SPU's -- secondary > processors with only 256kb of local memory. It looks like out of the box > the memory footprint of libvorbis is roughly:'Tremor' is xiph's fixed-point decoder. It also has a branch called Tremor-lowmem, specifically designed for low memory footprint. Whilst for a cell SPU the fixed-point thing isn't particularly useful, the design of the decoder in other ways is appropriate for any low-memory system. Also, Tremor-lowmem will probably run just fine on an SPU anyway, even if it's not using the floating point hardware... Mike
Ethan Fenn schrieb:> But, before I dive into that I was wondering if anyone has any > experience with this sort of thing and could give me some idea of how > much work it's likely to be.Short answer: You can't. You will at least need to keep some representation of the codebook header in memory, and as the codebook size is not limited in the Vorbis specification, it is not possible to implement a complete Vorbis decoder with specific memory limits. Long answer: I suppose 256kB ought to be enough for most Vorbis streams. I don't know the reference decoder good enough to understand why 130kB code and 60kB static data is needed. Except for the floor lookup table (256 floating point entries), a Vorbis decoder should not need a substantial amount of other static data and the code size must be somehow optimizable. Tor
Some more information about the SPU's: (all public) - Unified scalar/vector register file (128 x 128bits) - Otherwise very similar to PPC Altivec - Fast DMA engine can access anything in main memory at behest of SPU. Tremor would not be ideal, this is a floating-point machine, but it is sensitive to memory footprint. -Dave ________________________________ From: vorbis-dev-bounces@xiph.org [mailto:vorbis-dev-bounces@xiph.org] On Behalf Of Ethan Fenn Sent: Thursday, March 08, 2007 10:34 AM To: vorbis-dev@xiph.org Subject: [Vorbis-dev] low-memory vorbis decoding Hi all, Does anyone have any experience porting libvorbis to platforms with small total memory sizes? Specifically, I'm trying to figure out if it's feasible to run Ogg Vorbis decoding on one of the PlayStation 3's SPU's -- secondary processors with only 256kb of local memory. It looks like out of the box the memory footprint of libvorbis is roughly: ~130k code ~60k static data ~160k heap So clearly there's some work to be done. I have some ideas of things to try... speed isn't a huge issue so I could eliminate some of the lookup tables (e.g. for mdct and windowing), and I could try to tease apart the analysis/synthesis code, as it looks like a lot of code on the analysis side is needlessly being linked in. But, before I dive into that I was wondering if anyone has any experience with this sort of thing and could give me some idea of how much work it's likely to be. Thanks, -Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20070308/7f90153c/attachment.html