diff options
author | Kevin P. Fleming <kpfleming@digium.com> | 2005-07-25 23:13:20 +0000 |
---|---|---|
committer | Kevin P. Fleming <kpfleming@digium.com> | 2005-07-25 23:13:20 +0000 |
commit | 8703628608a3eb0f075ed6f9555e16ad68107688 (patch) | |
tree | 2f3ee15e3fa6433e515ed99e7c63d09eb3a2829c /channels/chan_iax2.c | |
parent | f6c059d451c8cecec852786460a8110daead7fac (diff) |
add explanatory comment about timestamp compensation (bug #4763)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@6217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'channels/chan_iax2.c')
-rwxr-xr-x | channels/chan_iax2.c | 22 |
1 files changed, 17 insertions, 5 deletions
diff --git a/channels/chan_iax2.c b/channels/chan_iax2.c index 93d27262a..cdb640ea0 100755 --- a/channels/chan_iax2.c +++ b/channels/chan_iax2.c @@ -3420,11 +3420,23 @@ static unsigned int calc_timestamp(struct chan_iax2_pvt *p, unsigned int ts, str if (voice) { /* On a voice frame, use predicted values if appropriate */ if (p->notsilenttx && abs(ms - p->nextpred) <= MAX_TIMESTAMP_SKEW) { - /* Adjust our txcore, keeping voice and - non-voice synchronized */ - /* We need someone who understands this code to comment here on - why the 'adjust' value is handled as if it was in units - of 10,000 microseconds, instead of milliseconds + /* Adjust our txcore, keeping voice and non-voice synchronized */ + /* AN EXPLANATION: + When we send voice, we usually send "calculated" timestamps worked out + on the basis of the number of samples sent. When we send other frames, + we usually send timestamps worked out from the real clock. + The problem is that they can tend to drift out of step because the + source channel's clock and our clock may not be exactly at the same rate. + We fix this by continuously "tweaking" p->offset. p->offset is "time zero" + for this call. Moving it adjusts timestamps for non-voice frames. + We make the adjustment in the style of a moving average. Each time we + adjust p->offset by 10% of the difference between our clock-derived + timestamp and the predicted timestamp. That's why you see "10000" + below even though IAX2 timestamps are in milliseconds. + The use of a moving average avoids offset moving too radically. + Generally, "adjust" roams back and forth around 0, with offset hardly + changing at all. But if a consistent different starts to develop it + will be eliminated over the course of 10 frames (200-300msecs) */ adjust = (ms - p->nextpred); if (adjust < 0) |