Frau Ztdummy. "zis ist mein klok! [ka-WHAP], unt you vill be schlaif to it! [wha-BANG}"
Nuns with wooden spoons . . . Nice. Make her in her mid-20s, though--Asterisk is still young. Only Andrew could take something as boring as telecom, and make it downright kinky! > -----Original Message----- > From: Andrew Kohlsmith [mailto:[EMAIL PROTECTED] > Sent: March 23, 2006 11:25 AM > To: [email protected] > Subject: Re: [on-asterisk] Timing Device Hardware (zaptel > interfaces) and Software (ztdummy) > > On Thursday 23 March 2006 02:29, Reza - Asterisk Enthusiast wrote: > > My question is quite simple: What is the real purpose of a > "timing device" > > for Asterisk, and in this * case, what really is a "timer". > Is it just a > > traditional "timing" device keeping track of time etc... > or something > > more? > > As Jim mentioned, the telephone network requires a > "metronome" to ensure that all points are in sync with each > other. That's the purpose of this timing device. It's a > periodic tap on the shoulder saying "you need to do something > now," except when it comes to telephony it's not just your > wife tapping you on the shoulder every five minutes hoping > that this time you'll put the computer down and do what needs > to be done; it's an 80-year old German nun with a Swiss time > institute-calibrated stopwatch and a big bruise-inducing > wooden spoon tapping you on the shoulder at PRECISE and > CAREFULLY MEASURED intervals. When she taps, you must accept > an audio frame from her (well 8, see below) and you must also > give her an 8 audio frames. If you don't, she is going to > beat you with that spoon. > > That's kind of what it's like with telephony. When the clock > says it's time to move, you must move. You must exchange a > full frame of information (I'm simplifying here, but I can > get obscenely technical if you like) or you will have a > condition known as a frame slip -- either you will drop > information from them, or they will get partial information > from you. Either way it's > bad. Your conversations start to get little buzzes and > chirps in them, or > you can get a fragment of someone else's conversation in your > own, etc. You don't want to do that, you want to work in > lock-step with whoever you're connected to. The timing > devices provide the mechanism or drumbeat to make sure you > work this way. > > > We all take it for granted that it provides some sort of timing > > feature/mechanism that is needed for Asterisk to function > properly, if > > we wish to have the MeetMe function or the Music On Hold > function... > > to supposedly improve the sound quality of the music when > MoH is activated. > > It's the nun I mentioned above. It's the mechanism that > Asterisk uses to ensure that the voice traffic is handled in > lock-step with the rest of the system. > > > The exact same answers I have continued to receive is, "You > need the > > timing device for the MoH & MeetMe function... if you want > * to work > > well... you need it... you have no choice... ztdummy isn't good > > enough so it's best that you have a zaptel hardware to > provide accurate timing capability". > > -- and of course my question comes back to "what is this > timing capability" > > and then there is no answer. > > Telephony works on a 125us period. That's 8000 "exchanges of > information" a second. Zaptel processes 8 of these at a time > to try and get the interrupt rate down to a more reasonable > level, which is why you get 1000 interrupts a second with Zaptel. > > Computers are powers-of-two systems. As such, almost > everything revolves around some 2^n number. RTC and USB > clock sources are no exception. You can get a 1024Hz > interrupt out of the RTC or USB, but you can't get 1000Hz. > If it sounds like it's "close enough" it isn't. You are > pressing to exchange information (in this case 8 audio > frames) faster than that data is actually available. Over > the course of a second, you want to process 24*8 more frames > than anyone else you're connected to. They either return a > "bugger off" > return code to you or they fake the information. Either way > it sounds bad. > > The newer ztdummy code does try to smooth this out by > dropping interrupts to try and maintain an overall 1000Hz > interrupt rate, but it's still not perfect. There is some > mention of a software phase-locked-loop implementation for > ztdummy that should help quite a bit, but I haven't seen any > code for it yet. Ultimately you want 1000 interrupts a > second and if you don't have EXACTLY 1000 interrupts per > second, you will eventually slip frames and your voice > quality will go down. The more often you slip, the worse it > will sound. > > Remember that MeetMe (for example) is mixing an arbitrary > number of audio sources. Everyone has to agree on how much > data per interval they are going to send. If everyone sends > 20ms of data at a time everything is great and it sounds > good. However if you have some SIP phones sending enough > data for 20ms and Asterisk is taking that and mixing it > together just slightly faster than 20ms (in the case of > ztdummy), or if you have some phones sending 20ms of data at > a time and another Asterisk system sending 20ms of data every > 18ms (duplicating or fudging data to make it fit) and the box > running MeetMe is mixing everything every 977us instead of > every 1000us... well you can see > how this becomes a nasty little problem. It's like trying > to put a puzzle > together after your kids have taken every puzzle in the house > and mixed it into one box. (not that this has ever happened > with my kids, nooooo.) It'll almost work, but it just won't > be as pretty as it could be if you just had pieces of all the > same size, and from only one puzzle. > > > So... here are my questions again in brief: > > 1.. What really is a Timing Device in Asterisk? > > 2.. Why do we need this for the MoH & MeetMe function? > > Answered above. > > > 3.. Is ztdummy good enough in a 100% VOIP setting (100% > of traffic > > is through your NIC)? 4.. Does ztdummy have any limitations when > > compared to timing devices in ZAPTEL interfaces? 5.. Does ztdummy > > utilize a lot of CPU process? > > Ztdummy isn't required for 100% VOIP systems unless MeetMe or > MOH is used, for the reasons outlined above. Until (very) > recently, Asterisk relied on the far-end to send packets at > exact intervals, because Asterisk used the packets themselves > as the timing source. For anything on the LAN this is okay, > but as soon as you introduce lag or jitter or dropped > packets, things fall apart fast. The SIP and IAX2 jitter > buffers are "self-timed" meaning they use an internal timer > to schedule when audio must be squirted out, which is the > proper way to do this. > > If there is no audio to send when it's time (i.e. when that > nun taps you on the shoulder and you don't have something to > give her) what do you do? You can't give her nothing so you > either fake it and give her an approximation of what you > think the finished product should be (this is called Packet > Loss Concealment, very cool), or you give her a copy of the > last bit of information and hope she doesn't notice, or you > might give her an empty shell, but you give her something. > Thankfully the nun doesn't care what you give her, but she > will take that to someone else and give it to them, and if it > doesn't have what was expected, they'll start doing things > like asking "Pardon? I didn't make out that last word. What > did you say?" and eventually "Your phone system sucks. I'm > going to call Jim and ask him for a Norstar system, because > VOIP just sucks." > > > 6.. Technically the ztdummy under Linux 2.4 utilizes the UHCI-USB > > which is the hardware minus the FXO/FXS - so why would > ztdummy not be > > good enough? > > This is incorrect. UHCI is the host-side. Certain USB host > controllers have a timer on them which ztdummy can use. It's > like the RTC driver though -- powers of two are in vogue, not > powers of ten. So 1024Hz is what you get, not 1000Hz. > > > 7.. In Linux 2.6, according to " > > http://www.voip-info.org/wiki/view/Asterisk+timer ", > ztdummy uses high > > resolution kernel timer. Is this "high res. kernel timer", 100% > > software driven, or takes advantage of the internal > hardware clock on > > the motherboard or takes advantage of the UHCI/OHCI USB > controller? I > > guess people who work with or write device drivers will truly > > appreciate my questions. Would love to hear thoughts & inputs on > > these theoritical questions, my soul is seeking for, up > until it finds > > other things to ponder about :) > > Basically the kernel has the resources to provide a good > 1000Hz software interrupt. I believe that the original > decision to tie MeetMe/MOH to zaptel was to try and lock > people into Digium hardware. Software timers are good enough > for most applications. Anytime you are tying to the PSTN > through digital means (PRI, T1/E1), you want to use their > clock source, though. > > The SIP and IAX2 PLC jitter buffers both use software timers > for the 20ms interrupt, and they work reasonably well. My > personal opinion is that unless your system's hideously > overtaxed you will have no trouble with a pure software > timer, provided that the kernel can deliver exactly 1000 > interrupts per second (which it can). If you're connecting > to Real Telco Hardware, you want to let them lead, so to speak. > > Hopefully this addresses your questions. > > -A. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.0/290 - Release > Date: 23/03/2006 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.0/290 - Release Date: 23/03/2006
