[Tremor] Implementing Tremor on low-end ARM

[Nicholas Vinen]

hb at x256.org wrote:
> Just flexibility, I was trying to work out which allocations might be
> freed during file opening or playback. In the end it turned out that only
> one place actually frees any memory until ov_clear is called, which is
> fwdindex, and that's why I treated it separately.
>   
Sorry, this fwdindex business is actually the result of confusion on my 
part. I accidentally got two allocations confused, that of the 
"forwardindex" and that of a block of temporary memory which it used in 
the mergesort() function.

It's the mergesort() function which performs the only actual call to 
free() prior to ov_clear(). I don't see why that malloc() can't be 
replaced with an alloca(). Assuming it can be, then all the calls to 
malloc() will never be freed until the call to ov_clear() and thus can 
be contiguously allocated in a static block of memory.

-----------

On a separate issue.. I have my player working quite nicely but right 
now I'm dealing with a separate issue. I'm using the Tremolo code which, 
besides the addition of ARM assembly routines may be slightly modified 
in other areas. The problem I'm having is that when playing back a 
corrupt file, when it hits the corrupt bit it seems to lock up or 
otherwise misbehave. When playing this file on my desktop, the checksum 
fails and it then skips a large bunch of corrupt data before resuming 
playback. On the ARM it seems to lock up before it even hits the 
checksum failure. I'm wondering if all data is checksummed, or if it's 
possible for some corrupt data to be passed into the player and mess up 
its working before it detects the next, corrupt page? If not then I have 
to work out why it's not detecting the checksum failure.


Nicholas