Don Pearce wrote:
On Sun, 26 Sep 2010 22:27:09 +0100, "DAB sounds worse than FM"
wrote:

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.

It very much depends on exactly how live is live. I don't suppose
anyone would be any the wiser if there was, say, a fifteen second
delay in the broadcast.


If you're suggesting that the first 15 seconds of audio be sent as quickly
as possible to fill the buffer up then to top that up, to make the stream
more robust than using, say, a 5 second buffer size, someone else suggested
that on alt.radio.digital and I passed the suggestion onto someone who was
working on the BBC's Internet radio streams, but the response was that they
didn't want to do that because the delay would muck up things like the pips
(apparently quite a few people email the BBC complaining about the delay of
the pips on DAB) and people listening to the delayed Internet stream would
be disadvantaged for phone competitions. Personally, I couldn't care less
whether the stream were delayed by a minute or however long if it meant that
the stream were very robust, and I think the BBC should allow people to set
their own buffer size in the Settings on the iPlayer (they could always set
it to a low default), but I doubt the BBC would let people do that, to be
honest.


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

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