I think you are asking the wrong question here because you are confused about how TCP and buffering work. Case in point, it took me a moment to figure out that by m/s you meant milliseconds and not meters per second!
Anyway, a 50ms delay is absolutely mice nuts. On wireless we routinely deal with that sort of variance in the normal flow of packets, not to mention a few percent of packet loss. Even if you could adjust the buffer size, I am not sure what that would help you to illustrate. Is there an alternative failure mode (for example a competing product which does not recover as quickly), where you would like to show that streaming does not perform as well? If you could describe what that failure looks like, maybe we could suggest a test to illustrate it. If you want to show the difference between, say, a 50ms outage and a 250ms outage, then VOIP is probably the best thing to demonstrate. VOIP potocols, by design, sacrifice reliability in order to achieve real-time streaming with low latency. Squeezebox is the opposite - it plays from stored data which can be read into its memory as fast as the network will deliver it, even in a bursty manner, so the stream can continue even with heavy packet loss or a complete outage of several seconds. You couldn't make Squeezebox behave the same way just by reducing the buffer size, because TCP is *totally* different! -- seanadams ------------------------------------------------------------------------ seanadams's Profile: http://forums.slimdevices.com/member.php?userid=3 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
