Speex dev - Mar 2006 - Who is using the jitter buffer?

Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca>
wrote:
> 
> > I would think you might also do better if you interleaved packets when
> > you did this: instead of sending packets like this: [0,1] [2,3] [4,5] 
> > [6,7], send them like this: [0,2] [1,3] [4,6] [5,7] In this way, if
one
> > packet is dropped you don't lose two consecutive voice frames.
> 
> No, but you make the latency even worse. I think 01, 23, 45, ... is
> still probably best.
How about a compromise then: use 01, 23, 45, ... most of the time, but 
switch to 02, 13, 46, ... when single packets are getting dropped on a 
regular basis.  But, this would only pay off if:

1) Having only one packet dropped at a time happens frequently enough
2) [0,2] [lost] [4,6] really sounds much better than [0,1] [lost] [4,5]
3) You're putting a minimal number of frames into each packet (like 2)
4) You have enough control of your protocol to implement such a system

Still, it sounds like an interesting idea.  I like the idea of a system 
that adapts to network conditions in a smart way.  (This is the reason 
we use a jitter buffer, right?)  What I'm worried about is the code 
complexity of such a system becoming difficult to manage as more 
features like this get combined.

I almost wanted to say that even perfect correction of 40ms gaps isn't 
that useful, since humans can deal with these gaps on their own (even 
without interpolation) and not miss what was said.  But it's a matter 
of smoothing over an annoyance, which could very well be worthwhile.  
And maybe it could help a little if it happened to be adjacent to a 
larger packet loss event that caused bigger problems.

Tom

hm would it be best to send the packet with all lost information the time + 
x
where time is your transmition time and x as a timeshake, becouse your
client need to transmit continously.
Thats becouse the jitterbuffer needs to be the double of transmition time?
> Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> wrote:
>>
>> > I would think you might also do better if you interleaved packets
when
>> > you did this: instead of sending packets like this: [0,1] [2,3]
[4,5]
>> > [6,7], send them like this: [0,2] [1,3] [4,6] [5,7] In this way,
if one
>> > packet is dropped you don't lose two consecutive voice frames.
>>
>> No, but you make the latency even worse. I think 01, 23, 45, ... is
>> still probably best.
>
> How about a compromise then: use 01, 23, 45, ... most of the time, but
> switch to 02, 13, 46, ... when single packets are getting dropped on a
> regular basis.  But, this would only pay off if:
>
> 1) Having only one packet dropped at a time happens frequently enough
> 2) [0,2] [lost] [4,6] really sounds much better than [0,1] [lost] [4,5]
> 3) You're putting a minimal number of frames into each packet (like 2)
> 4) You have enough control of your protocol to implement such a system
>
> Still, it sounds like an interesting idea.  I like the idea of a system
> that adapts to network conditions in a smart way.  (This is the reason
> we use a jitter buffer, right?)  What I'm worried about is the code
> complexity of such a system becoming difficult to manage as more
> features like this get combined.
>
> I almost wanted to say that even perfect correction of 40ms gaps isn't
> that useful, since humans can deal with these gaps on their own (even
> without interpolation) and not miss what was said.  But it's a matter
> of smoothing over an annoyance, which could very well be worthwhile.
> And maybe it could help a little if it happened to be adjacent to a
> larger packet loss event that caused bigger problems.
>
> Tom
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
>