Packet delay
Packet delay
A stream of sampled audio packets are transmitted from the source (sn), received at the destination (rn), and played (pn), thus each packet experiences a delay before playout (dn)
If a packet arrives too late (r3 arrives after we should have started to play at p3), then there is a problem (for some or all of the third packet’s audio).
Transcript
[slide81] Now, we have this very complex relationship that can occur between the source and the destination, and when it's time to play it out. Right? Because the source sends the packet. The destination receives it at some time, buffers it for a period of time, and then plays it out. Why do we buffer? No, buffering, remember, will do what to jitter? It- It needs to jitter. No, we call it a de-jitter buffer. But is it really removing the jitter? No, it's re-timing it so we don't hear the effect of the jitter, because we've delayed it long enough that everything has had a chance to arrive before we play it. Right, that's our goal. But the cost is, we increase our delay. Right, so in this case, when we got to P3 there, we didn't receive it in time, we received it too late. So what do we play out then? Right, I'm waiting for this packet. I should play it, but it hasn't arrived yet. I need to send something out to the D to converter so that my listener hears something, what do I play? I can play comfort noise, or it turns out I can also just play the last packet that I just played out. Right, part of the last packet, maybe they'll not notice. Right, but we have to play something. We can't say, oh no, perfect silence, or again, someone's going to be very unhappy.