[Tremor] Implementing Tremor on low-end ARM

[Nicholas Vinen]

I submitted a patch to the mailing list a day or two ago but it's stuck
in moderation. So here's a URL for it:

http://x256.org/~hb/Tremor.patch <http://x256.org/%7Ehb/Tremor.patch>

It seems to work fine, at least with my test files. I didn't include a
function to clear the allocation counters between files, which is
necessary because I stubbed out most of the free() calls. Just set all
the "*_allocated" counters in tmem to 0 after you deinit the Vorbis
decode and before you reinitialise it.

I too would be interested to know under what circumstances the various
tables might grow. I tested up to 96kHz 24bit stereo with these buffer
sizes and it seemed to work fine. Yes, I will only support 1 or 2
channels since my player only has stereo output anyway.

I saw that macro, which looks like it's designed to limit the size of
certain memory blocks, although as I said decoding a 96kHz file didn't
seem to require extra memory anyway. It may be due to the way I encoded
it though. Perhaps other encoders could create files which would require
more memory. You may be right that the larger window size might only
occur at higher compression ratios than I have tried.


Nicholas


Ethan Bordeaux wrote:
> Hi Nicholas - this is all very interesting.  I have a similar need to
> remove the dynamic memory allocation with static allocations for my
> application.  Please keep us in the loop on your explorations!
>
> Also, if some of the more experienced Tremor users/developers could
> chime in here on maximum allocations for various parts of the codec I
> would really appreciate it.  I only need to worry about signals up to
> 2 channels which seems like it will simplify some of the allocations
> and let them easily resolve to a reasonable fixed value but other
> allocations it's not quite so clear what the limit is.  Nicholas, are
> you planning on limiting your system to mono or stereo Ogg Vorbis files?
>
> Lastly on memory usage, can someone comment on the "LIMIT_TO_64kHz"
> #define in a few places of the code?  It removes the largest window
> which saves some memory, but this causes the codec to fail on decodes
> of highly compressed audio files right?  What are the circumstances it
> is safe to enable this switch?
>
> Ethan
>
> On Sun, Nov 23, 2008 at 11:36 AM, Nicholas Vinen <hb at x256.org
> <mailto:hb at x256.org>> wrote: