> 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.
I've always wondered how you got 1000 ticks out of 1024 without a bit of inaccuracy. So if you are skipping 3 ticks per 1024, 3 intervals are going to be ~1.8ms apart. I can see why that would be a problem! What do you see as being the overhead of doing 4096 interrupts/second, given that the handler for at least 3096 of them is going to be _very_ fast? Any reason why not to go to 8192? Also, doesn't the 2.6 kernel run on 1khz timing? Why isn't this used (I'm sure there's a good reason, I'm just curious to know what it is!)? 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
