[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