proms 320kbps
 

On Sat, 11 Sep 2010 15:14:25 +0100, Jim Lesurf
wrote:

In article , Don Pearce
wrote:
On Sat, 11 Sep 2010 12:11:52 +0100, Jim Lesurf
wrote:

In article , Don Pearce
wrote:
On Sat, 11 Sep 2010 09:54:59 +0100, Jim Lesurf
wrote:


Do the Beeb even allow buffering on these services?

Depends on what you mean by "allow".


Well, consider a comparison with something like Youtube. When I use
that, I see the "downloaded" portion of the progress bar move swiftly
across to completion in not much more than a few seconds. the video
then effectively plays off my hard drive.

From what I've been told that is because the BBC iPlayer works in its
own way. The process is effectively dominated by the BBC wanting to
'wrap' it all into a Flash process So the iPlayer isn't necessarily
like Youtube, etc.

I thought Youtube videos were Flash - they certainly download with a
.flv postscript.

That does not mean that the Flash code you download and use is exactly the
same in both such cases. Flash is essentially a programming / scripting
language aimed at specific sorts of tasks. So the two organisations each
use it in their own ways.

Yes, you are right of course. But that sort of goes to the heart of my
comment on what the BBC "allow" by way of buffering.

d

proms 320kbps
 

In article , Don Pearce
wrote:
On Sat, 11 Sep 2010 15:14:25 +0100, Jim Lesurf
wrote:


I thought Youtube videos were Flash - they certainly download with a
.flv postscript.

That does not mean that the Flash code you download and use is exactly
the same in both such cases. Flash is essentially a programming /
scripting language aimed at specific sorts of tasks. So the two
organisations each use it in their own ways.

Yes, you are right of course. But that sort of goes to the heart of my
comment on what the BBC "allow" by way of buffering.

Yes, agreed. At present I don't know, but will see if I can find out. FWIW
trying setting the Flash 'allocation limit' for "what the bbc can store on
my machine" to 1MB didn't seem to help. Maybe their choice is ample for up
to 192k but lacks the elbow room to make 320k as reliable. Or the 1sec
dropouts I get are due to something else. Not clear at present.

I'll see how I get on this evening...

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

proms 320kbps
 

Don Pearce wrote:
On Sat, 11 Sep 2010 09:54:59 +0100, Jim Lesurf
wrote:

In article , Don
Pearce wrote:
On Fri, 10 Sep 2010 09:30:31 +0100, Jim Lesurf
wrote:



How is your broadband connection though?

Fast enough that I can normally watch the *TV* iPlayer without
problems if wish.

For reference I just checked using the BBC iplayer diagnostic and
for both my laptop and shuttle this gave 2400 kbps for download
speed and 2200 for streaming. I'd agree that isn't very fast. But
it should be ample for 320k *provided* the connection streams
reliably.

I also use 256/320 from elsewhere at times. The problem can be with
occasional brief delays. My guess is that this is simply a machine
somewhere along the way being temporarily otherwise occupied or
some packets going AWOL. Hence I suspect this is a matter of the
levels of buffering/retries/requests not being quite adequate.

Slainte,

Jim

Do the Beeb even allow buffering on these services?

Depends on what you mean by "allow".


Well, consider a comparison with something like Youtube. When I use
that, I see the "downloaded" portion of the progress bar move swiftly
across to completion in not much more than a few seconds. the video
then effectively plays off my hard drive. I don't get that with BBC
streams. There is clearly a small amount of buffering, but only a tiny
amount gets downloaded ahead of playing and certainly not the entire
programme. I don't know what management is available to the Beeb for
this, but I suspect they know lots of people don't watch whole
programmes, so they want to limit the amount of wasted data transfer
by preventing the buildup of a huge buffer. A result of not quite
getting the balance right here would be occasional dropouts.


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.



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

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

proms 320kbps
 

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.

d

proms 320kbps
 

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

proms 320kbps
 

Jim Lesurf wrote:
In article , Don Pearce
wrote:
On Sat, 11 Sep 2010 15:14:25 +0100, Jim Lesurf
wrote:


I thought Youtube videos were Flash - they certainly download with
a .flv postscript.

That does not mean that the Flash code you download and use is
exactly the same in both such cases. Flash is essentially a
programming / scripting language aimed at specific sorts of tasks.
So the two organisations each use it in their own ways.

Yes, you are right of course. But that sort of goes to the heart of
my comment on what the BBC "allow" by way of buffering.

Yes, agreed. At present I don't know, but will see if I can find out.
FWIW trying setting the Flash 'allocation limit' for "what the bbc
can store on my machine" to 1MB didn't seem to help.


You can calculate how large the buffer size required should be by timing how
long it takes for the stream to start playing after you clicked play -
buffer size = stream bit rate x delay.


Maybe their
choice is ample for up to 192k but lacks the elbow room to make 320k
as reliable. Or the 1sec dropouts I get are due to something else.
Not clear at present.


If the dropouts never last for longer than 1 second, all they'd need to do
is increase the buffer size by at least 1 second to eliminate them.


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

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

proms 320kbps
 

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.

d

proms 320kbps
 

In article , Don Pearce
wrote:

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.

FWIW I'm still in the middle of analysis so anything I say at present is
'provisional'. However your point about the meaning of 'live' prompts me to
report the following...

One thing I finally got a 'round tuit' for this time was to write some
simple programs to do time-correlations of different 'versions' of some of
the proms. e.g. 'listen again' versus '320kb live'. This has allowed me to
determine the time-alignments and levels of covariance/difference etc with
a time precision of 1 sample.

I have been surprised by some of the results. I'll say more about that when
I've finished the analysis and perhaps have some idea of causes. But one
comment is perhaps worth making now.

I had assumed that the 1 second 'gaps' in the 320kb live stream were simply
due to some blocks of data going AWOL. Thus, like tape dropouts, were
sections of audio I had not heard in the 320kb version. But my correlations
seem to show that the data stream resumed each time *with an increase delay
of about 1 second*. Hence they may in effect have been more like 'pauses'
than 'losses' - despite the stream being 'live'.

Curious result. Not yet certain of the details or reasons. Say more when I
know more. Currently wading though rivers of data. :-)

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

proms 320kbps
 

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