-----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
