Don Pearce wrote:
On Sun, 26 Sep 2010 17:42:01 +0100, "DAB sounds worse than FM"
wrote:

YouTube uses 'progressive download', because the videos are watched
on-demand. The R3 320k stream was a live stream, so you can't
download what hasn't been played out live yet.

As for the buffer size on the live streams, unless they're using
some fast stream start technology (and they've never mentioned that
they are), the delay from pressing play to when you hear the audio
start playing (assuming instantaneous data transfer and stream
setup) equals the size of the buffer in seconds - i.e. if the stream
takes 5 seconds to start playing after you press play, then the
buffer holds 5 seconds' worth of audio, or at 320 kbps the buffer
size would be 5 x 320k / 8 = 200 kB.

IMO, they should've used a longer buffer size than they did for that
experiment, because the bit rate level was higher.


This is true, but the same thing applies to iPlayer, which is a
pretty good equivalent of Youtube for its basic functionality. Despite
the whole file being available on the server, on a small amount of
buffer is available at any instant. It seems that for a slightly flaky
connection such as Jim's, the amount is inadequate.


The 320 kbps Proms stream was a live stream, though - i.e. it was delivered
live from the Proms, and it was the same as what you would've heard if you'd
have tuned into Radio 3 on FM, DAB etc. Live streams are more difficult to
make reliable than on-demand streams, such as YouTube videos or catch-up TV
and radio programmes on the iPlayer. With on-demand streams, as you say, the
whole file is stored on a server, so the server can send audio or video well
in advance of when it needs to be played. So with on-demand streams you can
use very large buffer sizes, and as you can send data well in advance of
when it's needed, it's easy to keep the buffer from running out of data.

With live streams, you can only send audio that's just been broadcast, which
obviously rules out sending audio in advance of when it needs to be played.
So live streams have to use a fixed buffer size, which is continually topped
up. Ideally from a reliability point of view you'd want the buffer size to
be as large as possible to minimise the probability of running out of data.
But the size of the buffer for live streams also determines how long users
have to wait before they hear the audio after they've pressed play. So it's
a trade-off, and IMO it would have been better to increase the buffer size
of the 320 kbps Proms stream to make it more reliable (because the bit rate
is pretty high), even though that would have meant people would have had to
wait a bit longer before audio started playing.



--
Steve - www.digitalradiotech.co.uk - digital radio news & info

The BBC's "justification" of digital radio switchover is based on lies