Does all of this mean that as the streaming data is delayed, then what
you hear gets more and more delayed in real time from the source? And
that it can never catch up, because you have to listen to the entire
content on the receiving end????
Or do you end up somewhere with a "skip" of no content so that the
program at the receiving end doesn't get overly delayed relative to the
source?
Certainly not an issue if you're listening/watching an episode of
"Desperate Housewives" but a huge issue if you're listening to a horse race.
Randall wrote:
>>sound is digitally represented in a way that requires a fixed
>>amount of data per second. I.e. 64 or 128kbits/sec. When playing
>>the data must be consumed at a fixed rate that depends on the rate
>>it was encoded at.
>>
>>
>
>Only true if no compression is applied. Compression is pretty common, because
>of the huge amount of data involved.
>
>
>
>>Maybe an intermediate node goes down and there's a delay
>>while switching, or some extra traffic clogs part of the path that your
>>packets are using.
>>
>>
>
>Or maybe there's a marginal/noisy hop somewhere that is losing packets.
>
>One other thing that might be worth trying, if you have a hardware firewall or
>external switch/bridge/router at your end, is to substitute or temporarily
>eliminate it and see if the problem changes. I had a home-grade switch that
>dropped packets like crazy (when it wasn't locked up completely) ... replacing
>it did wonders for my effective bandwidth.
>
>Randall
|