[Asterisk-Users] PLC (Packet loss cancel) questions

[matt.riddell at sineapps.com]

On 27 Aug 2004 at 5:56, Kevin Walsh wrote:

> matt.riddell at sineapps.com wrote:
> > On 27 Aug 2004 at 2:33, Kevin Walsh wrote:
> > > There is no packet loss concealment in Asterisk at this time.
> > > 
> > Why doesn't asterisk clock to the 1000 interrupts per second instead
> > of the incoming audio?  Were there no interrupts available when it
> > started?  Even if you had no card you could use the ztdummy module
> > and even though that might be off by a bit, surely it'd sound better
> > than a connection which is experiencing packet loss?
> >
> I'm note sure what you're referring to with the "1000 interrupts per
> second."  Asterisk, as it stands, only reacts to incoming frames. If
> nothing is received then nothing is sent.  The authors obviously
> didn't take packet loss into consideration.

Ah, yeah the 1000 interrupts was referring to the interrupts 
generated off the digium cards (and why they don't much like 
interrupt sharing)...

Yeah I know, it has implications in silence detection as well as PLC. 
I kinda meant why doesn't someone fire off whenever the interrupts 
add up to 20ms (or whatever size packet the voip traffic is coming in 
in) and process packets then...(not that I know much about the 
internals).

> When a packet is received, the expected time of the next packet is
> calculated.  A while ago, I proposed that some sort of "empty frame"
> frame could be scheduled for "now + next ETA".  The "arrival" of the
> empty frame would wake up the receiver and, with the help of the
> jitter buffer, it could determine whether to pass on that frame to the
> translator, or to drop the packet as a "duplicate".  Some codecs could
> recognise the empty frame as a trigger to run their perform packet
> loss concealment code, whereas others (with no PLC) could simply treat
> it as a silent frame.

Hmmm, this sound good.

> This all seems possible to me, but I haven't seen a discussion
> relating to this proposal nor any other alternatives.
> 
Take this over to -dev?

Matt Riddell

-- SNIPPED REST --