[Tremor] Implementing Tremor on low-end ARM

[Nicholas Vinen]

Andy Grundman wrote:
> On Nov 24, 2008, at 11:22 PM, Nicholas Vinen wrote:
>
>   
>> 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.
>>     
>
> 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
>   

Interesting. I just did some testing. I took two files that play fine
with the statically allocated Tremor, concatenated them, and tried to
play the result.

What seems to happen is that when it hits the second Ogg stream, it
tries to allocate a number of things ("bookparam", "dectable", "work2"
and "mdct2") without having deallocated the previously used buffers.
This causes my code to abort.

I think the solution will be for me to figure out why it's doing this
and fix it. I don't know that it's related to static memory usage or
not, and I don't know if it's a leak as such, possibly just not very
clever memory management - i.e. it keeps old data allocated which is no
longer needed, and probably only deallocates it at the end of playback.

I'll get back to you if I manage to fix it up so that the transition
between the two streams doesn't require memory above that required to
play either stream individually.


Nicholas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/tremor/attachments/20081125/8787021e/attachment-0001.htm