[Tremor] Implementing Tremor on low-end ARM

[Nicholas Vinen]

Ethan Bordeaux wrote:
> Nicholas - I know you said you're not planning on supporting very low 
> encoding rates, but I just wanted to point out to everyone that 
> encoding with aoTuVb (v5.5) and q -2 you end up with the largest 
> memory needs I've seen thus far; 46474 bytes.  I've only tried one 
> file thus far so this number might grow a bit depending on the input.
You can increase the amount of static memory in allocation.c to anything 
you like. As long as that number, and your stack, is large enough it 
should play. On the system I am developing with 64K of RAM, I don't 
think it would be possible to allocate this much and still have enough 
left for file and audio buffers.

Note that very high quality levels can have higher memory requirements 
than average (q=5, q=6) levels, although the lowest qualities do seem to 
require the most playback RAM.
> One interesting thing I've noticed is that memory usage is mostly 
> (though not perfectly) constant at a particular encoding rate 
> regardless of input data.  For instance q 0 seems to always require 
> 34159 bytes and q 5 takes 35651 bytes.  This breaks down a bit at the 
> higher rates where they jump between a couple different values.  Also, 
> if you decode a very short and very simple file the memory needs can 
> be lower, but once the input is of "song length and complexity" these 
> numbers really stabilize.
Yes, the numbers are fairly consistent for a given quality level, but 
this may just reflect the behavior of the particular encoder we're 
testing. I don't know how much we could rely on that if people started 
modifying the encoder parameters or making their own encoders.
>
> One question I have is whether or not I need to test on encoders other 
> than oggenc2 (with and without aoTuVb).  Does anyone know if earlier 
> encoders malloc'ed for more memory?  Also, does anyone know if there 
> are plans on the encoder side to change the algorithm such that it 
> will send more codec init data?  I won't have any control over what 
> files are sent through the final implementation so I'd really hate to 
> lose compatibility with whatever is planned for future oggencs.  If 
> the algorithm is updated for wavelets that's one thing, but if the 
> underlying methods don't change and more memory is required I'd like 
> to do what I can to cope with this case.
>
It's a good question.


Nicholas