[Tremor] Implementing Tremor on low-end ARM

[Nicholas Vinen]

Andy Grundman wrote:
> Hi Nicholas,
>
> I'm quite interested in your patch, especially the comment-skipping  
> code.  I am also interested in Nate Weibley's work on the same issue.   
> Nate: How is your patch coming?
>
> Your static memory patch is interesting because of another bug we have  
> around memory allocation.  Have you tested your patch with multiple  
> Vorbis streams concatenated together (chaining/sequential  
> multiplexing)?  This is common in Ogg radio streams, and we have some  
> memory issues surrounding this.
>
> -Andy
> _______________________________________________
> Tremor mailing list
> Tremor at xiph.org
> http://lists.xiph.org/mailman/listinfo/tremor
>   
OK, I was mistaken in my last reply. Now that I've added code to some of
the free() functions I had stubbed out to deallocate some of the
statically allocated blocks, it's able to play two files concatenated
without running out of memory.

Here is my updated patch:

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

This also features some improvements on the previous patch, such as
automatically resetting the static memory allocation upon calling
ov_clear() so that it is immediately ready to open another file.

I recommend testing it by compiling like this:

CFLAGS="-DSTATIC_ALLOC -DSTATIC_ALLOC_DEBUG -DLOW_MEMORY_COMMENT_TRUNC"
./configure
make
gcc -DSTATIC_ALLOC -DSTATIC_ALLOC_DEBUG -DLOW_MEMORY_COMMENT_TRUNC -o
ivorbisfile_example ivorbisfile_example.c .libs/libvorbisidec.a

If you can find files that make it abort due to out of memory conditions
etc. I would be interested to have a copy so that I can see what's going
on and hopefully fix it. My goal is to, if possible, enable playback of
virtually any mono or stereo file (within reason) using less than 44Kb
of RAM.

I suspect that my comment skipping code may not work properly with all
comment sizes, I'll have to test it more. I know it works fine with
small comments and with hugs ones, but there may be problems dealing
with those of intermediate size (>1kB, <4kB).

Unfortunately because of my limited knowledge of the Ogg internals I
implemented a rather brute-force approach which is basically to truncate
any pages >4kB. This seems to work fine as the only pages in my test
file that are that large are the huge comments. Luckily everything else
is well under that so it's left alone. However, it may be possible that
under some circumstances files could contain other pages this large with
different data, in which case playback would likely fail. I'd like to
identify any of these if possible and find a way to work around it.

Additionally, at the moment running out of memory does a printf and
calls abort(), but when I'm loading this onto my embedded system (which
I will be building shortly), obviously that's not very good. I'm
thinking I'll replace this with a call to longjmp() which will return
control to the main software and allow it to handle the error.


Nicholas