> That's basically my question: the timestamps at thesource and> destination are not related. Just incrementing bynumber of samples> doesn't really convey the real time, does it? How woulda 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 bynumber of samples> doesn't really convey the real time, does it? How woulda 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?> .ahow 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