[Asterisk-Dev] Re: jitterbuffer
Steve Kann
stevek at stevek.com
Wed Apr 13 10:50:34 MST 2005
Jesse Kaijen wrote:
> Hi,
>
> I noticed that some people don't understand what I want to establish,
> so here is some explanation.
>
> The possibility of changing a codec during a call can have various
> impacts on the perceived audio quality.
> We all want the best audioperception and there are a few variables
> that have impact.
> They are: codec, delay, loss and jitter.
> Jitter can be handled by a jitterbuffer and results in more delay
> (and/or loss).
>
> So there are still 3 variables left.
> In our target environment we have no influence on delay and loss by
> the network (open Internet!), but we do have on the jb_delay and
> jb_loss. However jb_delay can be a trade off against jb_loss.
>
> Let's say we have three codecs available. ulaw, GSM, ILBC.
>
> ulaw: best_quality, high_bandwith, terrible with loss
> GSM: high_quality, low_bandwith, mediocre with loss
> ILBC: good_quality, low_bandwith, good with loss
I'm not sure why you state that uLaw is worse than GSM with loss..
Since they both use the same PLC method, and uLaw is stateless, it will
do much better in the presense of loss. It will also probably do better
than iLBC in terms of quality all around.
> Assumption 1: we always want the best achievable audio quality and we
> have little or no influence on the network.
> Assumption 2: user is stupid and/or can't give information of the
> connection.
> Assumption 3: 'program' has to give best solution for all types of
> connections, without manual reconfiguring.
>
> In a private network the end-end delivery is perfect ==>> ulaw.
> modem-connection ==>> GSM || ILBC
> internet-connection:
> if there is low traffic (no loss) ==>> ulaw
> if there is traffic and some loss ==>> GSM
> high traffic with losses ==>>ILBC (if your kids uses Kazaa, kill
> Kazaa and use ulaw)
> (extreme scenario: send more packets to push Kazaa 1d10ts out of the
> link)
>
> With ILBC the loss is not resolved, but user perception will be better
> because ILBC uses FEC/PLC techniques.
In the current asterisk and iaxclient implementations _every_ codec now
has PLC support (well, maybe not G.723/G.729, but soon, I guess).
I don't think that iLBC uses FEC, but it is mostly stateless, such that
the loss of a frame doesn't upset it's model as much as other compressed
formats.
-SteveK
More information about the asterisk-dev
mailing list