[Tremor] Fwd: Patch: static allocation (no heap) and handling large comment fields with limited memory

[Nicholas Vinen]

Oh, I just realised that when the patch I referred to in my last e-mail
got stuck in moderation, so did the instructions for using it. They're
important so here they are. As I said in my last e-mail I didn't provide
a function to reset the static allocation, which you need to do before
you re-initialise the decoder each time, but all you have to do is zero
out all the counters in the tmem object. You don't have to touch the
actual memory blocks.

Here's the URL again, in lieu of an attachment:

http://x256.org/~hb/Tremor.patch


-------- Original Message --------

I don't know how much interest there is for a patch like this, but in
case there is, I thought I would provide it.

It does two things. By default, I believe, it does nothing. That is if
you apply it and compile as normal it should work as normal.

However, if you define STATIC_ALLOC during compilation (e.g.
CFLAGS="-DSTATIC_ALLOC" ./configure) then instead of using _ogg_malloc
etc. it will use a set of static allocation functions set out in
allocation.c. An approx. 41Kb data structure is initialized in the data
segment and all the requests for memory come out of this. Note that at
the end of playback, nothing is really freed. The idea is that you can
just go and set the allocation counts to 0 bytes, and you know that all
the memory has been "freed" and can be re-used on the next file. This
should be convenient for embedded systems.

If you also define STATIC_ALLOC_DEBUG, it will print an error and abort
if any of the static memory blocks are exhausted, and it will print a
summary of the static allocation during playback if you use the example
player, like this:

Static memory used: 41616 bytes
dectable 14602/14602  bufdata 6144/8192  work2 8192/8192  mdct2 4096/4096
bookparam 2816/2816  fwdindex 48/96  misc 1452/3584



It's possible to make it use less than 40kB, but it's currently set up
so that it can handle a moderate amount of data in the comments field if
it is present (see next paragraph).


This brings me on to the second thing that this patch adds. If you
define LOW_MEMORY_COMMENT_TRUNC as well (e.g. CFLAGS="-DSTATIC_ALLOC
-DLOW_MEMORY_COMMENT_TRUNC" ./configure) then what it does is, if it
encounters a very large comment field (>4Kb) it discards all but the
first 1Kb of it. This is very handy for embedded players as it will
enable playback of files with embedded cover art etc. without exhausting
memory and without losing the comments field entirely. Generally the
first few fields will be artist, title, etc. information and this will
be retained. It probably needs some tweaking, but at the moment it works
on my pathological test file as well as ordinary Ogg Vorbis files I have
encoded.


Any comments are welcome.



Nicholas