In article <[EMAIL PROTECTED]>, James Harper <[EMAIL PROTECTED]> wrote: > > > 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?
As the one who added 2.6 RTC support to ztdummy, I'm qualified to comment! The primary reason for ztdummy is to support SIP, IAX and MeetMe in a system with no Zaptel cards. It is quite adequate for that, although there is a patch on the bugtracker that aims to address a perceived weakness in it. However, I don't think ztdummy as it stands is quite accurate enough for governing TDMoE, because it doesn't maintain a 1ms spacing. Since the RTC can only do power-of-2 subdivisions of a second, it is set to 1/1024 sec (0.9765625ms), but then 3 interrupts out of every 128 are skipped (evenly spaced) to give an average of 1000 per second. This is ok for VoIP with a 20ms or 30ms frame size, but not for TDMoE with a packet every 1ms. I would probably try making ztdummy use 4096 RTC interrupts per second and skip 3096 of them. This would make the interval between two consecutive packets either 0.9765625ms or 1.220703125ms. > 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... I personally don't think there's any value in this. > 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? Realistically speaking, the latter is much more likely to happen than the former, at least for the forseeable future! > I'll add it to the wiki for posterity if the end result is useful to > anyone else. That would be good. Cheers Tony -- Tony Mountifield Work: [EMAIL PROTECTED] - http://www.softins.co.uk Play: [EMAIL PROTECTED] - http://tony.mountifield.org _______________________________________________ --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
