search for: late_ratio

Is is possible to give a short hint about how the jitter buffer would "catch up" when network condition have been bad and then get better? I'm using the jitter buffer with success now, but sometimes I have a long delay that's caused by bad network conditions and then later when the conditions get better, I would think we would want the audio to gradually catch up with real-time

Thank you for a very good explanation which shed light on some of the questions that I had after reading the source code. Reading your text however, I wonder if I'm perhaps missing an important point on the proper use of the jitter buffer: ... > Now, clearly, if early_ratio is high and late_ratio is very > low, the buffer is buffering more than it needs to; it will > skip a frame to reduce latency. ... Question: Do I understand it that I should not put every incoming packet through the jitter buffer? The way my code works today is: 1) Packet read from socket 2) Call speex_jitter_...

...ives, the margin matching it's arrivel_margin is increased, so if this packet was 40ms after the current timestamp, the 40ms bin would be increased. If this packet arrived 60ms too late (and hence is useless), the -60ms bin would increase. early_ratio_XX is the sum of all the positive bins. late_ratio_XX is the sum of all the negative bins. The difference between _long and _short is just how fast they change. If a packet has timestamp outside the bins, it's not used for calculation. Now, clearly, if early_ratio is high and late_ratio is very low, the buffer is buffering more than it need...

...s arrivel_margin is > increased, so if this packet was 40ms after the current timestamp, the > 40ms bin would be increased. If this packet arrived 60ms too late (and > hence is useless), the -60ms bin would increase. Right. > early_ratio_XX is the sum of all the positive bins. > late_ratio_XX is the sum of all the negative bins. Right. And only the packets that are "just in time" don't get counted in any ratio. > The difference between _long and _short is just how fast they change. > > If a packet has timestamp outside the bins, it's not used for calcula...

...planation which shed light on some of the > questions that I had after reading the source code. > > Reading your text however, I wonder if I'm perhaps missing an important > point on the proper use of the jitter buffer: > > ... >> Now, clearly, if early_ratio is high and late_ratio is very >> low, the buffer is buffering more than it needs to; it will >> skip a frame to reduce latency. > ... > > Question: > Do I understand it that I should not put every incoming packet through the > jitter buffer? > > The way my code works today is: > >...

...planation which shed light on some of the > questions that I had after reading the source code. > > Reading your text however, I wonder if I'm perhaps missing an important > point on the proper use of the jitter buffer: > > ... >> Now, clearly, if early_ratio is high and late_ratio is very >> low, the buffer is buffering more than it needs to; it will >> skip a frame to reduce latency. > ... > > Question: > Do I understand it that I should not put every incoming packet through the > jitter buffer? > > The way my code works today is: > >...