Originally Posted by
StanleyB
There is a major flaw in the example that is critical in the case of an audio signal. The time it takes for the page to load is not critical. So if the HTML code loads first, followed by any pictures a few seconds later, it does not affect the final displayed page and no errors will be visible.
In audio however, time is critical. Each audio bit has to be in time and in place, otherwise drop out errors will be audible. Preventing or cutting down on obstacles that can combat drop outs is part of the exercise in this thread.
Stan, the way you put it, is as if the HTML page and all its components (pictures etc) were transmitted as individual mono-blocks.
But it doesn't happen like this, unfortunately. The HTML page and all its components are transmitted, stored locally and processed on the low-level components as a series of individual bytes. The order of their arrival is as important as their values. Much like in audio. If one single byte is out of order (or "arrives out of time") or its value altered, the page cannot be possibly displayed correctly.
I see what you mean, of course, but the components that use streaming protocols (without aknowledgment and error retry procedures) are only reserved for specific parts in audio. Hard disks don't use such protocols, for instance.
Dimitri.
In a time of deceit telling the truth is a revolutionary act.
George Orwell