I'm replying to my own message here, since I haven't gotten feedback of any kind from my previous message. I'd like to know if (Mark, mainly) will accept this change, and the main issue of concern about that is the most significant change integrating this will make..
It's certainly not perfect, but I've got PLC going with it, it's modular, and it was pretty easy to hook up to libiax2 (and would go into chan_iax2 pretty much the same way).
To use this jitterbuffer in chan_iax2, the biggest change is that it handles the queue of packets itself, instead of relying on the scheduler to handle them.
Presently, incoming frames are "scheduled" via the present jitterbuffer, and immediately inserted as events in the scheduler.
So, the question for integration is, how do we get the frames out of the buffer. There's two choices:
1) We could extend ast_chan_waitfornandfds (even more), so that it can handle this itself.
2) We can keep an event in the scheduler, for each channel, to dequeue the next frame.
(2) should be easy enough to do, because the jb API allows you to call jb_next(), and it will tell you when the next frame (real, or interpolated) is due out of the buffer. So, to do this, whenever we queue or dequeue a frame, we'd call jb_next, and adjust the scheduler entry as appropriate for the channel.
Next question:
In iaxclient, I implemented interpolation (a.k.a. PLC) by passing along voice frames with zero length data, but with the proper number of samples. I've modified the codec drivers there to interpret this as a request for interpolated frames. This would probably work for asterisk as well, although there might be cases we need to concern us with here (i.e. sending out a frame like this over VoIP to an endpoint that doesn't understand this; we should probably never transmit these kinds of frames via VoIP).
Finally, how would this be integrated into rtp.c, etc; how would applications/bridge situations turn off or tune the buffer for their needs? As I wrote in the requirements, I think the buffer should be on, except in cases where the channel is bridged to another VoIP channel, and the codecs are compatible. Otherwise, because the jitterbuffer adds PLC and stuff, you'd probably want it on. There's likely to be exceptions to this, though. For example, app_echo probably wants the jitterbuffer off, because the same activity will be handled when the frames are bounced back..
app_voicemail, app_record, etc all want it on, so that the recorded voice is clear. app_meetme/app_conference also need it on..
-SteveK
_______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
