[Speex-dev] New jitter.c, bug in speex_jitter_get?

Jean-Marc Valin Jean-Marc.Valin at USherbrooke.ca
Wed May 3 16:40:02 PDT 2006

> Yes.  Jean-Marc has made the API more similar.  
> Jean-Marc:  Have you looked at the API we have for the
> asterisk/iaxclient jitterbuffer?  

Just did.

> It's pretty close to what you have now -- the major difference is that
> your jb still assumes it can "own" the data passed in -- it copies it,
> and it destroys it at will.  With the API I put together, the
> jitterbuffer only keeps a poiunter to the data, and considers it
> opaque -- if it wants to destroy the data, it needs to return the
> pointer with a flag, and then the caller is responsible for whatever
> cleanup is needed.

Yeah, I wasn't sure about that one. The problem is what to do when you
need to discard. You seem to say you return it and ask the user to
destroy it (how?), but this seemed a bit error prone to me. And it's not
like copying data is that expensive compared to decoding it. Another
comment is that I think it's not a good idea to expose the jb structs in
the header file.

> Here's that API:
> http://svn.sourceforge.net/viewcvs.cgi/iaxclient/trunk/iaxclient/lib/jitterbuf.h?view=markup&rev=470

A couple things I don't understand. Why do you need both the local clock
and the remote clock and how do you define those anyway? BTW, does your
jitter buffer consider that there can be overlaps or holes between
frames, especially if using PCM?

> It would be cool if the speex JB could use a compatible API, then
> people could always mix/match these things, and see which one works
> best for different situations.

You could always write a sort of abstraction. I'm not sure if we could
use *exactly* the same API -- unless you wish to use the Speex one :-)
That being said, I'm open to changes, especially in cases where what I
have would be too limiting for a particular application. Any


More information about the Speex-dev mailing list