[Speex-dev] Jitter buffer (speex_jitter.h) usage

Zachary Schneirov z-schneirov at northwestern.edu
Fri Jan 30 11:16:43 PST 2009


Dear speex developers and users,

I'm considering adopting the speex jitter buffer for use with a  
different codec in a voice conferencing system and would be very  
grateful if those more acquainted with it could help me with some  
questions.

The speex_jitter_buffer.c wrapper seems to maintain (buffer?) one  
packet-frame ("current_packet") in addition to the packets already  
tracked by the JitterBuffer itself. Why is this necessary?

Correspondingly, how is the internal JitterBuffer state affected by  
calling jitter_buffer_get (and _tick) before jitter_buffer_put has a  
chance to deliver the first packet of a stream? Should this be avoided?

jitter_buffer_get can return JITTER_BUFFER_INSERTION and  
JITTER_BUFFER_MISSING. In both situations speex_jitter_buffer.c makes  
the codec interpolate a frame. How are these conditions different, and  
is there a better recommended strategy for handling one versus the  
other?

Am I correct that calling jitter_buffer_update_delay might eventually  
cause one or more buffered packets to be skipped? And in any case,  
what are the implications of having auto_adjust change the delay on  
every call to jitter_buffer_tick versus speex_jitter_buffer.c's  
strategy of making it contingent upon the "activity level" of the last  
frame? Is this equivalent to shrinking the buffer using some form of  
silence detection?

Thank you very much in advance.


Zach

---------------------------------------
Zachary P. Schneirov

Software Developer
WCAS Multimedia Learning Center
Northwestern University
(847) 467-5655



More information about the Speex-dev mailing list