Hi, first off I'm happy to see this list has sprung back to life. Vague accusations of unchecked in code can do that. :) Sorry if anyone's feelings were hurt by this thread, I appreciate the quick response.<br><br>
As for whether or not I'm on the latest version of Tremor that appears to be the case. I had assumed that there hadn't been any changes for a long time from looking at the changelog which ends on 20020517 and seeing a few mentions of problems with code not being merged back in from this mailing list. Now that I see there's a bug tracking mechanism (unknown to me as of 10 minutes ago) I can also see that there have been fixes made much more recently than 2002. I did a quick check on one of the most recently modified files (res012.c, changed 20070623) and I do have those fixes in place so I believe I'm up to date. Great.<br>
<br>Sorry about all that. It seems that the lowmem branch has every relevant pending fix rolled into it, right?<br><br>Now that that matter is cleared up, can anyone offer advice on my other questions?<br><br>1. Recommended audio signals to use for functional verification of Vorbis? I'm not so concerned with listening tests, just want to make sure my test vectors exercise as much of the codec as possible in as short a period of time as possible. I've done work on speech codecs before so I know that test vectors won't necessarily find all differences between the reference and the targetted code, but I'd like to do more than simply feed in some sine sweeps and noise and call it a day. Would an audio file with lots of transients of varying power and frequency content be a good place to start? Whenever I search for audio sample recommendations for codecs it's from the perspective of analyzing audio quality, not functionality.<br>
2. What sort of startup delay increase can I expect with lowmem vs "normal" Tremor? I know it's target dependent but ballpark figures would be nice (we're porting to ARM9 if that helps in the estimates). Are there other reasons to stay away from lowmem?<br>
<br>Thanks everyone.<br><br>Ethan<br><br><div class="gmail_quote">On Wed, Oct 29, 2008 at 2:56 PM, Frédéric Bastien <span dir="ltr"><<a href="mailto:nouiz@nouiz.org">nouiz@nouiz.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
you are right, it seem to be included in changeset<br>
<a href="https://trac.xiph.org/changeset/13164" target="_blank">https://trac.xiph.org/changeset/13164</a>. Maybe Ethan don't use the last<br>
version? Do you use<br>
<a href="http://svn.xiph.org/branches/lowmem-branch/Tremor/" target="_blank">http://svn.xiph.org/branches/lowmem-branch/Tremor/</a>?<br>
<br>
Fred<br>
<div><div></div><div class="Wj3C7c"><br>
On Sun, Nov 2, 2008 at 1:50 AM, Andy Grundman <<a href="mailto:andy@slimdevices.com">andy@slimdevices.com</a>> wrote:<br>
> On Oct 29, 2008, at 6:11 PM, Frédéric Bastien wrote:<br>
><br>
>> Hi,<br>
>><br>
>> I have see an explanation of the memory leak on the mailing list long<br>
>> time ago. So I implemented it and send on the mailing list a patch of<br>
>> the fix. I hoped that someone with access would commited it. If the<br>
>> last commit is from 2002, nobody commited it. So look in the archive<br>
>> of the mailing list for the patch and apply them.<br>
>><br>
>> Who have commit access to the repository? I think it is time to commit<br>
>> the patch after so long time. Especially if nodoby complained about it<br>
>> and it is a small patch to review. This will prevent this trouble from<br>
>> popping from time to time here. Is their any reason that it was not<br>
>> commited?<br>
>><br>
>> Here is the link to the message with the patch:<br>
>> <a href="http://lists.xiph.org/pipermail/tremor/2004-October/001112.html" target="_blank">http://lists.xiph.org/pipermail/tremor/2004-October/001112.html</a><br>
>><br>
>> this patch don't fix all memory fix, only the one that conserned me.<br>
>> So event if it don't fix everything, I don't see why it should not be<br>
>> accepted.<br>
><br>
> It does look like the memory leak patch was committed to trunk and lowmem.<br>
><br>
> However, I just checked our code and the _ogg_free call in<br>
> ogg_stream_destroy is commented out, with a comment pointing to<br>
> <a href="http://lists.xiph.org/pipermail/tremor/2004-April/000965.html" target="_blank">http://lists.xiph.org/pipermail/tremor/2004-April/000965.html</a> This could be<br>
> a bug in our code, but the way our memory allocation works I don't think it<br>
> matters, as all memory used at the end of playback is freed anyway.<br>
><br>
> Our implementation (Ubicom ip3k embedded system) is based on the lowmem<br>
> branch, but there is still a serious memory problem when reading large<br>
> comment headers. I'm still looking for a way around that.<br>
_______________________________________________<br>
Tremor mailing list<br>
<a href="mailto:Tremor@xiph.org">Tremor@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/tremor" target="_blank">http://lists.xiph.org/mailman/listinfo/tremor</a><br>
</div></div></blockquote></div><br>