[Home]

Summary:ASTERISK-04377: possible minor bug in chan_iax2.c:calc_timestamp()
Reporter:Luigi Rizzo (rizzo)Labels:
Date Opened:2005-06-08 15:18:04Date Closed:2011-06-07 14:10:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:this section of code in chan_iax2.c (near line 3458) caught my attention:

       /* Adjust our txcore, keeping voice and
          non-voice synchronized */
--->    add_ms(&p->offset, (int)(ms - p->nextpred)/10);

i don't understand the division by 10. Dimensionally, the second
argument should be milliseconds, and both p->nextpred and ms
are. The division by 10 changes them to 1/100 of second...

Possibly a false alarm, but just to understand...

       
Comments:By: stevekstevek (stevekstevek) 2005-06-13 17:01:08

OK.

So, what's happening here is this:

ms is the "current time" (in relation to the call).
nextpred is the "expected time of the next voice frame".

So, then this:
---> add_ms(&p->offset, (int)(ms - p->nextpred)/10);

adds 1/10 of the difference between the two to the offset.

The units for ms, nextpred, and the second argument to add_ms are still milliseconds.

===================
What this does, is gradually skew our "offset".  Offset is defined by this equation:

currenttime - offset = "milliseconds since beginning of call"

If you don't do this, then the problem you see is that sometimes the system clock (i.e. gettimeofday()), and the source of your audio signal (e.g. an audio card, the telephone system, a remote phone of some kind), have a skew relative to each other.

By adjusting "offset" in this way, we effectively clock our outgoing timestamps to the audio signal, when audio is present.

We only adjust by 1/10 to act as a low-pass filter -- we don't want a temporary spike to have a huge effect, but want to track continuous differences.
By: Luigi Rizzo (rizzo) 2005-06-13 17:08:12

ok then how about adding, in the code, a short comment to explain
what is going on ? something like

/* adjust the offset by a fraction (1/10) of the measured difference */
By: Joe Antkowiak (antkojm1) 2005-06-18 03:05:52

Would this be related to receiving thousands of messages like this?  If not I'll open another bug...

Jun 17 23:46:42 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (211) > max (160), using real ts instead.Jun 17 23:46:43 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:44 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:44 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:45 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:45 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:46 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:46 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (211) > max (160), using real ts instead.Jun 17 23:46:46 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:47 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:50 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:51 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.Jun 17 23:46:51 DEBUG[6177]: chan_iax2.c:3492 calc_timestamp: predicted timestamp skew (191) > max (160), using real ts instead.
By: Michael Jerris (mikej) 2005-06-18 08:09:08

antkojm1-Your getting debug messages, if you don't want to see them, turn off debug.
By: Mark Spencer (markster) 2005-06-18 12:22:30

Closing this one out.  Rizzo, perhaps it would be worthwhile to contact some of the authors of code first, rather than trying to place a bug in anticipation that something might be a bug.  We have very limited resources for handling bug tracking, and adding additional bugs makes it harder for us to examine all of the bugs that are currently in the system.