Displaying 4 results from an estimated 4 matches for "poiunter".
Did you mean:
pointer
2006 May 03
2
New jitter.c, bug in speex_jitter_get?
On 5/3/06, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca> wrote:
> > I must say I really like the generalized jitter buffer though :) It's a
> > cleaner and more flexible implementation and can more easily be adjusted
> > to contain additional information with each packet.
This looks interesting to tie into asterisk's jb and plc code as well.
2006 May 03
2
New jitter.c, bug in speex_jitter_get?
...xclient 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 see...
2006 May 03
0
New jitter.c, bug in speex_jitter_get?
...I we have for the
asterisk/iaxclient jitterbuffer? 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.
Here's that API:
http://svn.sourceforge.net/viewcvs.cgi/iaxclient/trunk/iaxclient/lib/jitterbuf.h?view=mark...
2006 May 03
0
New jitter.c, bug in speex_jitter_get?
...t;> 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
>...