[EMAIL PROTECTED] 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.
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. This all seems possible to me, but I haven't seen a discussion relating to this proposal nor any other alternatives. > > How much work would be required to change this? I guess it couldn't > really be an option because of the totally different structure... > I don't think it would take a radical rewrite to implement this. A discussion would be helpful in order to plan the best way to solve the problem, such as deciding upon best place to schedule the "empty frame" delivery - perhaps in ast_translate() - and the form that the empty frame trigger should take - perhaps a new AST_FRAME_PLC frametype. > > Would it be possible for one person to make those changes or would it > require the authors of all modules to recode? > One person could make the required changes. It may help to have input from the authors of the various source files, as the code is overly complicated in some places, and is poorly commented throughout. -- _/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/ _/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h _/ _/ _/ _/ _/ _/ _/ _/_/ [EMAIL PROTECTED] _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
