proms 320kbps
 

Surprised no-one else seems to have mentioned this here yet. :-)

http://www.bbc.co.uk/proms/2010/audioexperiment/

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
 

Jim Lesurf wrote:

Surprised no-one else seems to have mentioned this here yet. :-)

http://www.bbc.co.uk/proms/2010/audioexperiment/

There is a thread on alt.radio.digital.


--
David Pitt

proms 320kbps
 

Le 04/09/2010 18:46, David Pitt a écrit :
Jim Lesurf wrote:

Surprised no-one else seems to have mentioned this here yet. :-)

http://www.bbc.co.uk/proms/2010/audioexperiment/

There is a thread on alt.radio.digital.



Jim,

Perhaps you could use your vast influence at the Beeb [:-)] so that this
"experiment" continues after the The Last Night!

--
Froggy

Blackadder: There's something wrong with your fiancée, sir.
Melchett: Oh my God, she's not Welsh, is she?

(Blackadder Goes Forth)

proms 320kbps
 

In article , froggy
wrote:
Le 04/09/2010 18:46, David Pitt a écrit :
Jim Lesurf wrote:

Surprised no-one else seems to have mentioned this here yet. :-)

http://www.bbc.co.uk/proms/2010/audioexperiment/

There is a thread on alt.radio.digital.



Jim,

Perhaps you could use your vast influence at the Beeb [:-)]

sic :-)

so that this "experiment" continues after the The Last Night!

TBH at present I've not decided if for me 320k gives a satisfactory
trade-off between reliability of stream connection and quality. Dunno about
you, but so far, each time I've tried the current experimental stream I get
drop outs on average about once or twice an hour (about 1 sec lost each
time) which rather disrupts listening to a long piece of music. Wheras at
128k or 192k I almost never get such dropouts.

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
 

On 09/09/2010 09:33, Jim Lesurf wrote:
In , froggy
wrote:
Le 04/09/2010 18:46, David Pitt a écrit :
Jim wrote:

Surprised no-one else seems to have mentioned this here yet. :-)

http://www.bbc.co.uk/proms/2010/audioexperiment/

There is a thread on alt.radio.digital.



Jim,

Perhaps you could use your vast influence at the Beeb [:-)]

sic :-)

so that this "experiment" continues after the The Last Night!

TBH at present I've not decided if for me 320k gives a satisfactory
trade-off between reliability of stream connection and quality. Dunno about
you, but so far, each time I've tried the current experimental stream I get
drop outs on average about once or twice an hour (about 1 sec lost each
time) which rather disrupts listening to a long piece of music. Wheras at
128k or 192k I almost never get such dropouts.

Slainte,

Jim


Steve the digitalradiotech fella has just sent his round his email list,
fyi etc:

***
The BBC has launched an "experimental" 320 kbps AAC Internet stream
carrying the Proms. The stream will be available until the Last Night of
the Proms on Saturday 11th September, and the BBC would like people to
listen to the stream while the Proms are on, then to provide feedback by
filling in a short online questionnaire.

As it is an extreme rarity for the BBC to care about the audio quality
it delivers on digital radio, let alone experiment with a bit rate as
high as 320 kbps, I would urge as many of you as possible to have a
listen to this stream and to fill in the online questionnaire afterwards.

The 320 kbps AAC stream can be found he

http://www.bbc.co.uk/proms/2010/audioexperiment/

The online questionnaire is he

http://ecustomeropinions.com/survey/...?sid=471224792

And a BBC Internet blog about the "extra high quality audio experiment"
can be found he

http://www.bbc.co.uk/blogs/bbcintern...ity_audio.html

***

proms 320kbps
 

In article , Rob
wrote:
On 09/09/2010 09:33, Jim Lesurf wrote:


Steve the digitalradiotech fella has just sent his round his email list,
fyi etc:

Thanks. FWIW I'd already had the same info from the BBC directly - ahem
minus, of course, Steve's added opinions. :-) IIUC the survey and blog
should also be findable from the URL I posted when I started this thread.

I'd certainly encourage people to try it while they can and report their
experience.

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
 

On Thu, 09 Sep 2010 09:33:22 +0100, Jim Lesurf
wrote:

In article , froggy
wrote:
Le 04/09/2010 18:46, David Pitt a écrit :
Jim Lesurf wrote:

Surprised no-one else seems to have mentioned this here yet. :-)

http://www.bbc.co.uk/proms/2010/audioexperiment/

There is a thread on alt.radio.digital.



Jim,

Perhaps you could use your vast influence at the Beeb [:-)]

sic :-)

so that this "experiment" continues after the The Last Night!

TBH at present I've not decided if for me 320k gives a satisfactory
trade-off between reliability of stream connection and quality. Dunno about
you, but so far, each time I've tried the current experimental stream I get
drop outs on average about once or twice an hour (about 1 sec lost each
time) which rather disrupts listening to a long piece of music. Wheras at
128k or 192k I almost never get such dropouts.

Slainte,

Jim

How is your broadband connection though? I pay a little extra for the
professional option from Plusnet. It guarantees maximum line bandwidth
on all ports and services. I was downloading the latest TomTom Western
Europe map the other day, and had the network monitor running to see
how it was going. Here is what the monitor made of most of the
transfer.

http://www.soundthoughts.co.uk/look/adsl.png

Rock solid 16Mb/sec and no dropouts. That is about 1GByte on that
display. That makes light work of 320kb/sec.

d

proms 320kbps
 

"Don Pearce" wrote

How is your broadband connection though? I pay a little extra for the
professional option from Plusnet. It guarantees maximum line bandwidth
on all ports and services.

That's all very well if you live close enough to the exchange. If, OTOH, you
have 4km of overhead cable between you and the exchange (as I do) 16Mb/s is
the stuff of fantasy. Just 10% of that would be a dream!

David.

proms 320kbps
 

On Thu, 9 Sep 2010 20:41:07 +0100, "David Looser"
wrote:

"Don Pearce" wrote

How is your broadband connection though? I pay a little extra for the
professional option from Plusnet. It guarantees maximum line bandwidth
on all ports and services.

That's all very well if you live close enough to the exchange. If, OTOH, you
have 4km of overhead cable between you and the exchange (as I do) 16Mb/s is
the stuff of fantasy. Just 10% of that would be a dream!

David.


You mean you wont move house just to increase your broadband speed?
What kind of commitment is that?

d

proms 320kbps
 

In article , Don Pearce
wrote:
On Thu, 09 Sep 2010 09:33:22 +0100, Jim Lesurf
wrote:


TBH at present I've not decided if for me 320k gives a satisfactory
trade-off between reliability of stream connection and quality. Dunno
about you, but so far, each time I've tried the current experimental
stream I get drop outs on average about once or twice an hour (about 1
sec lost each time) which rather disrupts listening to a long piece of
music. Wheras at 128k or 192k I almost never get such dropouts.

Slainte,

Jim

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

--
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
 

On Fri, 10 Sep 2010 09:30:31 +0100, Jim Lesurf
wrote:

In article , Don Pearce
wrote:
On Thu, 09 Sep 2010 09:33:22 +0100, Jim Lesurf
wrote:


TBH at present I've not decided if for me 320k gives a satisfactory
trade-off between reliability of stream connection and quality. Dunno
about you, but so far, each time I've tried the current experimental
stream I get drop outs on average about once or twice an hour (about 1
sec lost each time) which rather disrupts listening to a long piece of
music. Wheras at 128k or 192k I almost never get such dropouts.

Slainte,

Jim

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? I never see the
progress bar moving beyond the point in the programme that has been
reached. I think that if there is even a brief glitch in the stream,
you will hear it.

d

proms 320kbps
 

In article , Jim Lesurf
scribeth thus
In article , froggy
wrote:
Le 04/09/2010 18:46, David Pitt a écrit :
Jim Lesurf wrote:

Surprised no-one else seems to have mentioned this here yet. :-)

http://www.bbc.co.uk/proms/2010/audioexperiment/

There is a thread on alt.radio.digital.



Jim,

Perhaps you could use your vast influence at the Beeb [:-)]

sic :-)

so that this "experiment" continues after the The Last Night!

TBH at present I've not decided if for me 320k gives a satisfactory
trade-off between reliability of stream connection and quality. Dunno about
you, but so far, each time I've tried the current experimental stream I get
drop outs on average about once or twice an hour (about 1 sec lost each
time) which rather disrupts listening to a long piece of music. Wheras at
128k or 192k I almost never get such dropouts.

Yes thats happening here. I haven't bothered to check the other streams.
Mind you theres a couple of TV progs of iplayer being used elsewhere
here;!..

--
Tony Sayer

proms 320kbps
 

In article , Don Pearce
scribeth thus
On Thu, 09 Sep 2010 09:33:22 +0100, Jim Lesurf
wrote:

In article , froggy
wrote:
Le 04/09/2010 18:46, David Pitt a écrit :
Jim Lesurf wrote:

Surprised no-one else seems to have mentioned this here yet. :-)

http://www.bbc.co.uk/proms/2010/audioexperiment/

There is a thread on alt.radio.digital.



Jim,

Perhaps you could use your vast influence at the Beeb [:-)]

sic :-)

so that this "experiment" continues after the The Last Night!

TBH at present I've not decided if for me 320k gives a satisfactory
trade-off between reliability of stream connection and quality. Dunno about
you, but so far, each time I've tried the current experimental stream I get
drop outs on average about once or twice an hour (about 1 sec lost each
time) which rather disrupts listening to a long piece of music. Wheras at
128k or 192k I almost never get such dropouts.

Slainte,

Jim

How is your broadband connection though? I pay a little extra for the
professional option from Plusnet. It guarantees maximum line bandwidth
on all ports and services. I was downloading the latest TomTom Western
Europe map the other day, and had the network monitor running to see
how it was going. Here is what the monitor made of most of the
transfer.

http://www.soundthoughts.co.uk/look/adsl.png

Rock solid 16Mb/sec and no dropouts. That is about 1GByte on that
display. That makes light work of 320kb/sec.

d

Lucky you!. Here we're on VM and very good that is too, their 10 meg
service, does all we need they can do a 20 and a 50 IIRC, but there are
people less than three miles from Cambridge who can barely muster 1 Meg
whilst paying for 8 on god ole BT ally cable;(...

If the BBC wanted to improve their digital broadcasting then UP the
rates on Freeview and Freesat, as I might have muttered before the
Germans can manage 334 K for their Klassik service why can't olde auntie
BBC.

OK, this is a step in the right direction and as time goes on the net
may become the platform of choice, well until theres a lot more Fibre to
the home or nearer.. like what VM do.

And then theres the net connection and PC to the living room or place
when the good audio system is. I have got a satellite receiver that has
got LAN facilities on but its not too easy to get that to decode the
stream required and fortunately we have a house wired for CAT 5 and a 24
port switch most domestic premises aren't so well equipped and Radio on
2.4 or 5.8 is OK but in some premises the interference experienced
nowadays is limiting..

And for most a noisy PC added to the living room complement, whereas a
digital sat receiver is quite commonplace and a much easier way of
receiving the higher quality "Radio" Broadcast signals;)...
--
Tony Sayer

proms 320kbps
 

"tony sayer" wrote

OK, this is a step in the right direction and as time goes on the net
may become the platform of choice, well until theres a lot more Fibre to
the home or nearer.. like what VM do.


Yes, but fibre to the home cost money, and who is going to pay? The public
have been lead to believe that access to the internet should be really cheap
so resent paying the money that would allow adequate investment in the
infrastructure. So unless the government can be persuaded to stump up the
cash (unlikely in the present circumstances!) this country is likely to
continue to suffer from a patchy quality of internet service.

David.

proms 320kbps
 

In article , David Looser
scribeth thus
"tony sayer" wrote

OK, this is a step in the right direction and as time goes on the net
may become the platform of choice, well until theres a lot more Fibre to
the home or nearer.. like what VM do.


Yes, but fibre to the home cost money, and who is going to pay? The public
have been lead to believe that access to the internet should be really cheap
so resent paying the money that would allow adequate investment in the
infrastructure. So unless the government can be persuaded to stump up the
cash (unlikely in the present circumstances!) this country is likely to
continue to suffer from a patchy quality of internet service.


I quite agree David. But the net was a sort of data info place like a
large file server for not that big docs. Its grown since and perhaps we
need or someone somewhere needs to grow. I don't suppose whatsisname who
dreamt it up would have foreseen iplayer etc..


However give her her due, old auntie BBC has scored on this one as most
all of the comments on the "experiment" have shown...

Course they could up the rates on satellite a much more practical method
of digital radio "broadcasting" and simpler for most all users too, just
a skyboxen or digital sat receiver;)).. No TV side PC required;!..


http://www.bbc.co.uk/blogs/bbcintern...xtra_high_qual
ity_audio.html
--
Tony Sayer

proms 320kbps
 

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".

Yes, the stream is certainly bufferred. If I monitor the data transfers
with gnome-system-monitor I can see a graph of how the transfer rate varies
with time. And with the 128/192k 'normal' services it is easy to see the
flickering of the lights on my router varying in sympathy with this.

For the 128/192k streams I tend to get a low steady level, and every few
tens of seconds a 'burst' or higher rate transfer. So I assume the steady
rate is just slightly too low to keep the rx buffer up to target and an
occasional burst is called for to help fill it to a higher level.

The difficulty is that I suspect this all takes place interactively under
control of the Flash code. So not easily changable by the user. The problem
then becomes that any delays or underfilling may mean that the 320k rate
exhausts the RX buffer and it then takes time to refill.

If you think about it, aac is a spectral block code. So the data *must* be
buffered to some extent - albeit only for a few blocks if the transfer was
utterly reliable and ultra-fast.

Shame the test is so short. One thing I wanted to try was altering the
workspace assigned to the Flash plugin to see if that helped. Alas, I often
can't use a 'live' service as 'real world' (TM) interrupts take priority.
So occasions for me to participate in the public test are limited. Since
the 1sec gaps are rare I need some time to get any meaningful stats.

And I've now found that up here in the frozen north we are *not* going to
be allowed to see the first half of the 'Last Night' from the RAH! Instead
we are being given an 'opt out' for what looks like it may be a 'shortbread
and tartan' alternative from Dundee. I won't say my reaction as it isn't
for delicate ears! :-) Oh well, at least we have Radio 3 where the
pictures are better, anyway. But it means I won't have a 'BBCTV Freeview'
version for the first half as a comparison.

Or would someone would be willing to make either a (English) Freeview or
FreeSat LPCM wav recording of the first half on TV for me to analyse?

I never see the progress bar moving beyond the point in the programme
that has been reached. I think that if there is even a brief glitch in
the stream, you will hear it.

The progress bar tends to be too crude a display for this and tends to show
what has been played or 'elapsed'. And brief gaps tend to be 'faded' by the
system, so not as abrupt as you might assume. 1 sec is obvious. But smaller
ones may easily pass unnoticed.

All being well, I'll be able to say more when I've finished collecting data
and do some analysis. Currently working on some more analysis routines to
go with the ones I already have.

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
 

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.

Yes, the stream is certainly bufferred. If I monitor the data transfers
with gnome-system-monitor I can see a graph of how the transfer rate varies
with time. And with the 128/192k 'normal' services it is easy to see the
flickering of the lights on my router varying in sympathy with this.

For the 128/192k streams I tend to get a low steady level, and every few
tens of seconds a 'burst' or higher rate transfer. So I assume the steady
rate is just slightly too low to keep the rx buffer up to target and an
occasional burst is called for to help fill it to a higher level.

The difficulty is that I suspect this all takes place interactively under
control of the Flash code. So not easily changable by the user. The problem
then becomes that any delays or underfilling may mean that the 320k rate
exhausts the RX buffer and it then takes time to refill.

If you think about it, aac is a spectral block code. So the data *must* be
buffered to some extent - albeit only for a few blocks if the transfer was
utterly reliable and ultra-fast.


Yes, but that is, as you say, a necessary buffer to allow extraction
of the error-corrected signal.

Shame the test is so short. One thing I wanted to try was altering the
workspace assigned to the Flash plugin to see if that helped. Alas, I often
can't use a 'live' service as 'real world' (TM) interrupts take priority.
So occasions for me to participate in the public test are limited. Since
the 1sec gaps are rare I need some time to get any meaningful stats.

And I've now found that up here in the frozen north we are *not* going to
be allowed to see the first half of the 'Last Night' from the RAH! Instead
we are being given an 'opt out' for what looks like it may be a 'shortbread
and tartan' alternative from Dundee. I won't say my reaction as it isn't
for delicate ears! :-) Oh well, at least we have Radio 3 where the
pictures are better, anyway. But it means I won't have a 'BBCTV Freeview'
version for the first half as a comparison.

Or would someone would be willing to make either a (English) Freeview or
FreeSat LPCM wav recording of the first half on TV for me to analyse?

I never see the progress bar moving beyond the point in the programme
that has been reached. I think that if there is even a brief glitch in
the stream, you will hear it.

The progress bar tends to be too crude a display for this and tends to show
what has been played or 'elapsed'. And brief gaps tend to be 'faded' by the
system, so not as abrupt as you might assume. 1 sec is obvious. But smaller
ones may easily pass unnoticed.

All being well, I'll be able to say more when I've finished collecting data
and do some analysis. Currently working on some more analysis routines to
go with the ones I already have.

Slainte,

Jim

I'll be interested.

d

proms 320kbps
 

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.

FWIW I've just checked and my Flash setup was limiting the BBC to just
100kB of space. So I've changed that to 1MB in case I get a chance to see
if that makes any difference.

All being well, I'll be able to say more when I've finished collecting
data and do some analysis. Currently working on some more analysis
routines to go with the ones I already have.


I'll be interested.

One preliminary result may interest you. This is that some 'continuity' and
'interval talk' portions have a large number of very short sequences of
zero-value samples.

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
 

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.

FWIW I've just checked and my Flash setup was limiting the BBC to just
100kB of space. So I've changed that to 1MB in case I get a chance to see
if that makes any difference.

All being well, I'll be able to say more when I've finished collecting
data and do some analysis. Currently working on some more analysis
routines to go with the ones I already have.


I'll be interested.

One preliminary result may interest you. This is that some 'continuity' and
'interval talk' portions have a large number of very short sequences of
zero-value samples.


Huh?

d

proms 320kbps
 

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.

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
 

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