[Asterisk-Dev] Channels, jitterbuffer and PLC?
Steve Kann
stevek at stevek.com
Tue Apr 12 19:38:43 MST 2005
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
>
More information about the asterisk-dev
mailing list