[Tremor] fixed vs float audio performance, lowmem branch, and latest memory leak fixes?

[Ethan Bordeaux]

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.

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.

Sorry about all that.  It seems that the lowmem branch has every relevant
pending fix rolled into it, right?

Now that that matter is cleared up, can anyone offer advice on my other
questions?

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.
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?

Thanks everyone.

Ethan

On Wed, Oct 29, 2008 at 2:56 PM, Frédéric Bastien <nouiz at nouiz.org> wrote:

> Hi,
>
> you are right, it seem to be included in changeset
> https://trac.xiph.org/changeset/13164. Maybe Ethan don't use the last
> version? Do you use
> http://svn.xiph.org/branches/lowmem-branch/Tremor/?
>
> Fred
>
> On Sun, Nov 2, 2008 at 1:50 AM, Andy Grundman <andy at slimdevices.com>
> wrote:
> > On Oct 29, 2008, at 6:11 PM, Frédéric Bastien wrote:
> >
> >> Hi,
> >>
> >> I have see an explanation of the memory leak on the mailing list long
> >> time ago. So I implemented it and send on the mailing list a patch of
> >> the fix. I hoped that someone with access would commited it. If the
> >> last commit is from 2002, nobody commited it. So look in the archive
> >> of the mailing list for the patch and apply them.
> >>
> >> Who have commit access to the repository? I think it is time to commit
> >> the patch after so long time. Especially if nodoby complained about it
> >> and it is a small patch to review. This will prevent this trouble from
> >> popping from time to time here. Is their any reason that it was not
> >> commited?
> >>
> >> Here is the link to the message with the patch:
> >> http://lists.xiph.org/pipermail/tremor/2004-October/001112.html
> >>
> >> this patch don't fix all memory fix, only the one that conserned me.
> >> So event if it don't fix everything, I don't see why it should not be
> >> accepted.
> >
> > It does look like the memory leak patch was committed to trunk and
> lowmem.
> >
> > However, I just checked our code and the _ogg_free call in
> > ogg_stream_destroy is commented out, with a comment pointing to
> > http://lists.xiph.org/pipermail/tremor/2004-April/000965.html  This
> could be
> > a bug in our code, but the way our memory allocation works I don't think
> it
> > matters, as all memory used at the end of playback is freed anyway.
> >
> > Our implementation (Ubicom ip3k embedded system) is based on the lowmem
> > branch, but there is still a serious memory problem when reading large
> > comment headers.  I'm still looking for a way around that.
> _______________________________________________
> Tremor mailing list
> Tremor at xiph.org
> http://lists.xiph.org/mailman/listinfo/tremor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/tremor/attachments/20081029/0a1119db/attachment.htm