[Tremor] Implementing Tremor on low-end ARM

[Andy Grundman]

On Nov 25, 2008, at 11:22 AM, Nicholas Vinen wrote:

> Peter Harris wrote:
>>
>> Nicholas Vinen wrote:
>>
>>> 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.
>>>
>> Lower quality files tend to use longer blocks, and therefore use more
>> memory in the decoder. Try encoding a file at -q 0 (or lower). Even
>> then, the tables won't be as large as the spec allows.  
>> Unfortunately, I
>> don't think there are any pathological test files available.
>>
>> Peter Harris
>>
>
> OK, I tried encoding a file at every integer quality setting between  
> -1 and 10
>
> Interestingly I found memory requirements did increase at lower  
> quality levels, but certain buffers grew at higher quality settings  
> too.
>
> I think what I am going to do is change my patch so that pretty much  
> everything is allocated out of a single buffer, the only exception  
> being those few/small chunks which actually get freed before the end  
> of playback. This should (a) simplify it and speed it up a bit and  
> (b) means that you only have to care about the maximum total memory  
> usage. The worst case I tested is quality -1 which required 46400  
> bytes. This is definitely in the upper limit of what I can spare on  
> a 64K system given that I calculated I need at least 12KB and  
> possibly 16KB of audio buffer! Those two alone exhaust practically  
> all RAM, and I need space for some file system buffers etc. I may  
> end up supporting -q0 through -q10 which, in this case at least,  
> reduces the memory requirement to 34412 bytes - a massive  
> difference! -q10 requires 39835 bytes, and going above this doesn't  
> seem to increase it.
>
>
> I also discovered my comment skipping patch breaks at certain  
> quality levels (e.g. -q4). After I fix up the static allocation I'll  
> have a go at improving this.

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