[Tremor] Implementing Tremor on low-end ARM

[Ethan Bordeaux]

Hi, I've integrated the basic static memory allocation from your patch into
my source and it seems to be working well.  Nice job.  I've decoded a few
hundred audio files at lots of different rates and haven't found any
instances where more memory has been needed.  None of the files have
metadata, FYI.  It gets pretty close to the maximum but never hits it.  I've
also tried encoding some files with the AoTuV vorbis encoder (via
oggdropXpd) and it doesn't seem to make larger files, though the allocations
are different for the same input and quality level.  I do have a general
nagging concern about memory allocations with older and yet implemented ogg
encoders which might have greater memory requests, but I'm not sure what can
be done about that.  Best you can do is test vigorously on a few popular
encoders and exit as graceful as possible if the pseudo static allocation
fails.

Is there any reason you changed the name of so many allocations in the
source files rather than going with a #ifdef for _ogg_malloc and the other
associated functions?  Was this just a development/debug decision or
something you feel is useful for the released code as well?

Lastly, this is a slightly more general question on the codec.  There are a
couple places where realloc is used in Tremor - this is definitely hard to
implement with this sort of static memory allocation.  However, after
running all these tests I have yet to find a case where realloc is actually
called - it only appears a couple times in the code.  Can anyone say if this
code is truly dead or is some fix to deal with realloc (most likely just
allocating for the whole amount immediately) going to be necessary?

Ethan

On Tue, Nov 25, 2008 at 2:48 PM, Nicholas Vinen <hb at x256.org> wrote:

> Andy Grundman wrote:
> > I tested your patch with one of my test files with a 100K artwork
> > comment, it's a -q9 file, and fails:
> >
> > STATIC MEMORY ERROR: tmem.bufdata exhausted (9216/8192)
> >
> > It also fails on a newly encoded -q9 file without any comments:
> >
> > STATIC MEMORY ERROR: tmem.dectable exhausted (15844/14602)
> >
> > This file is here: http://bugs.slimdevices.com/attachment.cgi?id=3261
> > _______________________________________________
> > Tremor mailing list
> > Tremor at xiph.org
> > http://lists.xiph.org/mailman/listinfo/tremor
> >
>
> It's because different allocations take up different amounts of space as
> the quality level changes. My latest patch allocates pretty much
> everything out of a single piece of memory, so if one thing grows and
> another shrinks it doesn't fail like that. Try this one:
>
> http://x256.org/~hb/Tremor3.patch <http://x256.org/%7Ehb/Tremor3.patch>
>
> I'm still a bit uncertain about the comment truncation code; it works on
> all my test files now (1k, 2k, 3k, 4k, 5k and 40k comments) but I'm
> really not sure that it won't break on some other size. Unfortunately I
> find the way the code parses the file rather mysterious and complex and
> I have too many other things to work out now to work it all out. I think
> the general approach is sound - ignore and discard the latter pages of
> large comment fields as they're being read in - but I've implemented it
> in a rather clumsy way.
>
>
>
> Nicholas
>
> _______________________________________________
> Tremor mailing list
> Tremor at xiph.org
> http://lists.xiph.org/mailman/listinfo/tremor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/tremor/attachments/20081216/ec797a17/attachment.htm