search for: jb_getal

> 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,

...ard. You seem to say you return it and ask the user to > destroy it (how?), but this seemed a bit error prone to me. We just return a frame with the return value JB_DROP, which tells the caller to drop this frame, and call jb_get again. When the caller is done with the jitterbuffer, it calls jb_getall() repeatedly, until it's empty, and then it can discard all the frames. > And it's not > like copying data is that expensive compared to decoding it. Perhaps it's not expensive, but it's unnecessary.. It also means that the jitterbuffer's pointers can point to str...

> We just return a frame with the return value JB_DROP, which tells the > caller to drop this frame, and call jb_get again. > > When the caller is done with the jitterbuffer, it calls jb_getall() > repeatedly, until it's empty, and then it can discard all the frames. Hmm, looks a bit error-prone to me. Especially considering I still have to explain that "no, you can't pass ulaw instead of float to speex_encode and expect 4x better compression" :-) > Perhaps it...

On May 3, 2006, at 9:12 PM, Jean-Marc Valin wrote: >> We just return a frame with the return value JB_DROP, which tells the >> caller to drop this frame, and call jb_get again. >> >> When the caller is done with the jitterbuffer, it calls jb_getall() >> repeatedly, until it's empty, and then it can discard all the frames. > > Hmm, looks a bit error-prone to me. Especially considering I still > have > to explain that "no, you can't pass ulaw instead of float to > speex_encode and expect 4x better compressio...