<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><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 bgcolor="#FFFFFF" text="#000000"><div class="moz-cite-prefix">The application using live555 has a BasicUDPSource that is
replicated through a StreamReplicator to feed a BasicUDPSink and
two FileSink.
<br></div></div></blockquote><div><br></div>I suspect that your problem is simply that the data rate of your input stream is too high for your system to handle. (If that's the case, then it has nothing to do with the LIVE555 code. Increasing the size of the "BasicUDPSource"s OS input socket buffer - using "increaseReceiveBufferTo()" - *might* alleviate the problem, but, if your input stream's data rate is too high, can never overcome it.)</div><div><br></div><div>In particular, if the two "FileSink"s are for files that are on the same disk, then many OS's file systems may not handle concurrent high-speed writes to these two separate files well; you could end up with lots of disk 'seeking', which will reduce throughput substantially. You can test this by having both of your "FileSink"s use the special file "/dev/null" (which doesn't do any actual disk writing). If you do this, I suspect that you'll see a lot less packet loss.</div><div><br></div><div><span style="orphans: 2; text-align: -webkit-auto; widows: 2;">Ross Finlayson</span></div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;">Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span>
</div>
<br></body></html>