[Speex-dev] Jitter buffer

[Steve Kann]

On Dec 22, 2004, at 12:38 AM, Jean-Marc Valin wrote:

> Hi Steve,
>
> Though it may work (haven't thought about all the details), I think it
> would be much more messy than just using a codec abstraction layer (the
> one in Speex or a custom one). I don't understand why you don't like
> that idea.
>

I guess I should have changed the subject of this message, because this 
API suggestion isn't really tied to the jitter buffer at all.

The codec abstraction in the jitterbuffer, though, assumes that the 
jitterbuffer will always be used for taking jittered input, and then 
decoding it to unjittered PCM.

That's not always what it's needed for, sometimes you just want to 
dejitter, and not decode.   Also, these operations often happen at 
differing places in a larger system, and coupling them so closely will 
require a much more complicated architecture.

Here's two examples of dejittering and not decoding:

1) iaxclient can handle an arbitrary number of calls, some of which may 
be active, and some of which may be "on hold".  For calls on hold, 
presently, we keep dejittering the input (so the buffer stays full, and 
we follow the network jitter), but we don't decode, because we're not 
playing the audio.

2) In asterisk, the jitterbuffer is presently at the network-protocol 
layer, but decoding is done much later.  Sometimes the call may be in 
an application which doesn't decode audio at all (i.e. it's playing you 
IVR prompts, or whatnot), or only decodes under certain circumstances 
(app_conference).  The network layer doesn't know anything about this.

-SteveK