> > When I referred to "lost packets", I was meaning from the perspective of > the Zaptel layer. In the current TDMoE implementation, there is absolutely > no jitter buffer. Packets can come in on the Ethernet with jitter, > depending on what else is sharing the LAN and the NIC, but the zaptel > driver expects to access readchunk and writechunk exactly on 1ms > intervals. > If a packet is late, then zaptel will see the previous chunk of data > again. If the subsequent packet is not late, then the previous late one > won't be seen by zaptel at all.
Ah. This makes some sense. > Paul Cadach mentioned something about a jitter buffer for TDMoE, but > I don't know whether he was talking about an idea or some real code. > > I'm also thinking about a jitter buffer, but it's tricky. I might > decide to combine ztdummy with ztdynamic/ztd_eth in order to make the > timing independent of incoming packets or other zaptel devices. The > jitter buffer only needs to be 1ms or 2ms in length. A jitter buffer adds delay though right? I guess 2ms fixed delay shouldn't cause a problem, but how would it work if tdmoe is your only source of timing? Is the 2.6 version of ztdummy widely held to be precise enough for our use? Assuming the source of TDMoE is an E1 line with exact timing, would there be value in using a statistical analysis of TDMoE data to correct ztdummy? Eg with x packets received from TDMoE over y time (for large enough values of y, and accounting for any dropped packets), it should be possible to compute the correct number of ztdummy ticks. If there is a variation compared to the actually number of ztdummy ticks, then add a fudge factor. Or maybe ztdummy drift isn't constant... If you ever get a spare moment, could you write some brief documentation on the flow of data from ethernet into zaptel and from zaptel out to the ethernet? Failing that, if I were to look through the code and write some doco, could you look at it and tell me where I messed up? I'll add it to the wiki for posterity if the end result is useful to anyone else. Thanks James _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
