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

> That's basically my question: the timestamps at the
source and 
> destination are not related. Just incrementing by
number of samples 
> doesn't really convey the real time, does it? How would
a jitter 
> buffer know that a packet is late/early?
Simple, I know what packet I just played. That gives me
the "time". The jitter buffer actually makes no
difference (and doesn't attempt to) between an increase
in the network delay and a drift in the soundcard clocks.
It just increments or decrements the buffer size to make
sure the packets spend the least amount of time in the
buffer (before being player), while not having too many
lost packets.



So, basically, the sound card play out requests serve as
a 'reference clock', right? 

Do you have plans to use silence packets to
grow/shrinking the jitter buffer?

.a

> That's basically my question: the timestamps at the
> source and 
> destination are not related. Just incrementing by
number of samples 
> doesn't really convey the real time, does it? How would
a jitter 
> buffer know that a packet is late/early?
> Simple, I know what packet I just played. That gives me
> the "time". The jitter buffer actually makes no
> difference (and doesn't attempt to) between an increase
> in the network delay and a drift in the soundcard clocks.
> It just increments or decrements the buffer size to make
> sure the packets spend the least amount of time in the
> buffer (before being player), while not having too many
> lost packets.

> So, basically, the sound card play out requests serve as
> a 'reference clock', right? 
> Do you have plans to use silence packets to
> grow/shrinking the jitter buffer?
> .a
how about tcp?
in tcp you write a packet that got a possible length.
you send one packet after another, whitch stamp is incrementet by one
and if your incoming packet is gone in other steps than 1, the client has
to resend it.
Let me think some days about it and i will get another system.
Time is relative.

Hm, you send a packet that needs to be in a possible chain of n.
Your jitterbuffer needs to be as long as you need to make your
transmition, and you would to send only one packet that contains
all lost packets... ?!? whats the matter ?!?

> So, basically, the sound card play out requests serve as
> a 'reference clock', right? 
Sort of, yes.
> Do you have plans to use silence packets to
> grow/shrinking the jitter buffer?
There are plans, but haven't done so yet. I'll keep that in mind when
changing the jitter buffer.

	Jean-Marc

> how about tcp?
> in tcp you write a packet that got a possible length.
> you send one packet after another, whitch stamp is incrementet by one
> and if your incoming packet is gone in other steps than 1, the client has
> to resend it.
> Let me think some days about it and i will get another system.
> Time is relative.
> 
> Hm, you send a packet that needs to be in a possible chain of n.
> Your jitterbuffer needs to be as long as you need to make your
> transmition, and you would to send only one packet that contains
> all lost packets... ?!? whats the matter ?!?
The matter is latency. If you want to have a conversation, you don't
want seconds of delay (every millisecond counts). TCP is out of the
question and so are retransmits. If the packet isn't in time, tough
luck. 

	Jean-Marc