[Asterisk-Dev] Channels, jitterbuffer and PLC?

[Steve Kann]

On Apr 12, 2005, at 8:25 PM, Steve Underwood wrote:

> Hi Steve,
>
> Do you think there is merit in having a-law to a-law and u-law to 
> u-law variants of the PLC code, so conversion is only needed when fake 
> data needs to be cooked up? Conversion is pretty lightweight, so I'm 
> not sure if there is much to gain. However, since the issue of needing 
> to pass everything through a linear step has come up a few times, the 
> question seems worth asking.

Possibly, although it can be done without it.  The only place this 
really comes up in practice, is when you're terminating to zap.

This can be handled in chan_zap itself, where, when PLC is enabled, and 
the channel is in xlaw mode, it stores each xlaw frame, and then passes 
it on.  When a INTERP frame is seen, it would then seed the PLC system 
by converting the stored frame to SLINEAR, call plc_rx() with it, to 
seed the plc system, then call plc_fillin() to get interpolated data 
(and convert that to xlaw).    Then, subsequent times, it either will 
call plc_fillin() again if another INTERP frame comes, or if a real 
frame comes, convert, call plc_rx(), and then convert back again.

I'm guessing that you just need one "real" frame to go through plc_rx 
after a sequence of INTERP frames, to smooth the transition.

I figure this is a bit of extra work (converting back and forth), but 
it only happens when INTERP frames are seen; otherwise, the xlaw data 
is just stored, so there's little overhead.

I imagine that you'd do pretty much the same thing with alaw to alaw 
and ulaw to ulaw variants of the PLC code?

Also, not written here, is the alaw to ulaw case;  Here, is the only 
transcoding that does not go through slinear, and PLC isn't applied in 
this case either, but, I think that if that transcoder would pass 
through INTERP frames, the xlaw PLC stuff described above would do it's 
magic then.

-SteveK


>
> Regards,
> Steve
>
>
> Steve Kann wrote:
>
>> The one problem you'll find for a full implementation is that 
>> presently, PLC only takes place upon translation from someformat -> 
>> slinear, and not the other way around, but if you only take slinear 
>> in, then you could do the PLC yourself (also, that's not too hard).
>>
>> But, now that I read your query again, this isn't what you want at 
>> all: If your side is TDM, you don't want a jitterbuffer there. You 
>> want the jitterbuffer on the receive side of the VoIP channels. So, 
>> assuming that RTP/chan_sip gets the jitterbuffer, and you're taking 
>> in slinear, it should all be good for you with no knowledge of the 
>> jitterbuffer or PLC going on.
>>
>> -SteveK
>
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>