seanadams;176146 Wrote: > I realize that's what you want to do, but it is not possible because you > are talking about a buffer size that is too small for TCP to stream > audio even on a perfectly good network. Even below the application > level, the OS presents a "receive window" (buffer size) to the other > side which must be large enough to allow the sender to keep sufficient > packets in flight to achieve the required data rate and to enable the > "fast retransmit" algorithm. > > Packet losses are a _NORMAL_ occurrence for TCP. That is, in fact, the > mechanism by which TCP determines how fast it can send data. So if you > were to design a setup which fails on a single packet loss, I can > guarantee it will fail independent of whatever simulation you're > applying. > > and we have barely scratched the surface yet... TCP is extremely > complex! 50ms is a very very small about of time as far as TCP is > typically concerned. It is so small that such an outage would be > practically impossible to detect at the application level. Isn't that > the whole reason why this is a selling point of the product? > > With a VOIP stream (which is not at all like TCP) you would be able to > hear short outages - maybe not 50ms, but at 100-200ms you could hear > short clicks.
Thanks Sean, I will keep looking for another application. As you aluded to, this is like pushing a square peg in a round hole. I did not think the TCP window size, would have a major impact here. I would have network mechanisms to help alliviate the sliding window (WRED)on prioritised traffic. As you can see I don't drag my head up past L3 to often, time to dust off the TCP rfc's.. Cheers, -- sfraser ------------------------------------------------------------------------ sfraser's Profile: http://forums.slimdevices.com/member.php?userid=2026 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 _______________________________________________ audiophiles mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/audiophiles
