[PATCH 8/9] Fixed (nanoBTS) delay problems, if RTP stream jitters too much

[Andreas Eversberg]

Jacob Erlbeck wrote:

dear jacob,
> void tv_add_us(tv, usec) {
>      struct timeval foo;
>      foo.tv_sec = usec / 1000000;
>      foo.tv_usec = usec % 1000000;
>
>      timeradd(tv, &foo, tv);
> }
> Which I then would write as
>
> tv_add_us(&rs->transmit.last_tv, USEC_20MS);
> tv_add_us(&rs->transmit.last_tv, sample_diff_excess * USEC_SAMPLE);
>
> And thanks to inlining the div/mod would vanish completely in the first
> case and would be without extra cost in the second. So no performance
> penalty but much better readability.
this makes sense. it simplifies things. i implemented it. by getting rid 
of negative usecs, there is no more issue about correctly decrementing 
the timeval.
> And did you understand the second application of tv_add() at first
> sight? It is correct but that is not obvious IMO.
the first implementation increments last_tv by the duration of one 
frame. (20ms) if too much time have been elapsed since when the last 
frame has been processed, the last_tv is additionally incremented by the 
duration of frames that have been missed since then. also the RTP 
timestamp and sequence number is incremented accordingly.

holger mentioned that you also had a problem with speech frames in 
conjunction with ipaccess BTS. was it a similar problem? how did you 
solve this?

best regards,

andreas