<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div fpstyle="1" ocsi="0" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><div>My name is Jon Anderson. I am working on an application using Live555 to stream L16 data for real-time audio playback at the lowest latency possible. I have stripped down many buffers on the OS side and have gotten my stream to playback with a latency of about 60 - 70 ms. My attention is now focused on Live555. I have notice several buffers built into Live555, but the only one that I am expecting to cause latency is the ReorderingPacketBuffer. For now, my plan is to get the latency down to as low as possible and then work it up for the sake of audio quality. With that in mind, I set the ReoderingPacketBuffer threshold time to 0ms.</div></div></div></blockquote><div><br></div>Note that the 'packet reordering threshold time' (default value: 100ms) will occur as latency *only* when a packet gets lost, or if packets arrive out of order. (In the latter case, the actual latency will be <= the threshold value.) If there's no packet loss or reordering on your network (which should be the common case if you're streaming over a LAN), then the 'packet reordering threshold time' will have NO effect on latency. But if packets ever arrive out of order, then the 'packet reordering threshold time' is important, otherwise the out-of-order packet(s) will get discarded.</div><div><br></div><div>Therefore, I don't recommend that you change this value, unless you're *certain* that packets will never get reordered on your network, but you expect packet loss to be quite common.</div><div><br></div><div><br></div><div><blockquote type="cite"><div fpstyle="1" ocsi="0" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><div>What other buffers might be causing audio playback delay?</div></div></div></blockquote><div><br></div></div>Nothing in the LIVE555 code. Note, however, that if you're using a media player (on the client side) to render and play the audio, then the media player will typically have a 'jitter buffer' that smooths out the incoming audio samples, before playing them. There's going to be some latency there - and it's unavoidable, because network jitter is unavoidable.<br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>