Proms 2017 in FLAC

[Dave2002]

Too late to test the theory now. The Pilot has ended, though it did run into Hear & Now and TtN. The binaural pilot has also ended, taking the catch up files with it.

I thought it was worth mentioning, as it seems on previous occasions service continued after the deadline. Maybe if there's another shot at this ....

[Dave2002]

Have most of us now sent in the feedback as suggested? [I haven't, yet]

Somewhere there is a page which asks if we would like the BBC to continue with such developments, possibly with a view to providing a more regular high quality audio stream at some future date.

Personally I didn't use it much, but that wasn't for lack of interest. When I did try it I was fairly sure it sounded better than the HD stream, but it did need good equipment, and not everyone has that or listens attentively or on good kit all the time.

[johnb]

Have most of us now sent in the feedback as suggested? [I haven't, yet]

Why on earth haven't you rated it?

One of the worrying things is that there are only 1,311 ratings and that lack of appreciation might well discourage the BBC from pursuing lossless streaming.

[johnb]

Too late to test the theory now. The Pilot has ended, though it did run into Hear & Now and TtN. The binaural pilot has also ended, taking the catch up files with it.

<Cough> It depends on which player you are using. (For now, the stream is still running but you need a different player to access it.)

[johnb]

The two minutes delay between streams makes me wonder if data is being buffered somewhere. With that much data buffer overflow conditions might occur which might indeed cause the dropouts and silences. If you restart the streams can you minimise the delay between the standard and the FLAC stream. You might need to turn some kit off then on to achieve this.

Possibly a reset procedure before listening will reduce problems - though not guaranteed.

The player will use a buffer but I doubt whether it overflows because, according to my understanding, with MPEG-DASH the player requests segments from the (BBC) server rather than the server pushing segments out to the player.

[OldTechie]

<Cough> It depends on which player you are using.

I guess the streaming and the website are run by different departments. There's probably nobody from the audio streaming side in at the weekend. I fear it may not last into next week.

On the 2 minute delay, I think most of it is intentionally designed into the player to cope with MPEG DASH. This sends larger chunks of data and allows for an imperfect Content Delivery Network by encouraging the player to keep a good buffer of data so the CDN can get behind and catch up. Watching the network traffic on startup I see this.



You can see a big download of data as it starts, followed by small blocks every 5 seconds or so. It looks as if the server limits the bandwidth per connection to about 2Mbps, though there was a slight spike at the very start. Sometimes it will change source server while playing. Heres a grab during a change:

[Dave2002]

The player will use a buffer but I doubt whether it overflows because, according to my understanding, with MPEG-DASH the player requests segments from the (BBC) server rather than the server pushing segments out to the player.

You may be right. Depends how it all works. In the past I have seen problems with streams - though admittedly most likely with video - where there were synchronisation issues. I believe some problems can arise because of drift - which may be very small and effectively insignificant over short periods (say under an hour), but if the streams are left running for days on end the drift can mount up.

You can sometimes spot this I think with different digital streams (e.g. satellite, DAB - radio or TV) and also compare with analogue channels if such still exist.

My observations with the streams I saw were that resetting the streams did reduce such problems considerably - though that was years ago and I may not be remembering all the details accurately.

Gaps could arise if drift became significant enough that the player detected it, and tried to correct that, but then we don't know how many players actually work - the design parameters of most systems tend to be generic and are only guidelines for developers. This is speculation, of course.

[johnb]

OT, thanks that is very interesting.

One thing about the bandwidth though. I run a utility that charts the internet bandwidth (rather line the screen grab you posted but with more detail).

From what I have observed, the bandwidth used by chunks of data varies with the complexity of the music. The chunks can and often do reach ~ 3.8Mbps during orchestral broadcasts.

e.g. this is a snippet as at 14:48 today:



[Edit] Having said that - it depends on what exactly the graph represents. I'm not sure which chart is gives a better overview.

[OldTechie]

John, my displays were from the Windows resource manager. I think it averages over 1 second before giving an answer - so a short peak always reads low. The slopes on the 5 second chunks are also just how they choose to display them. So I'm sure your display is probably more accurate.

The resource manager also displays the TCP connections. It includes connections that have been closed which time out a while later. They look like this on start up:



You can see multiple connections were made. The grey ones are closed and I think they were each used to get one 5 second chunk. The black one is the first connection.

Looking at the black one using netstat I find this (command was "netstat -anb > c:\temp.txt" so I could search for "vlc" in the output) :

TCP 192.168.1.112:55717 87.248.214.160:443 CLOSE_WAIT
[vlc.exe]

This is wrong. It means that the server closed the connection, but the player failed to respond properly and has hung on to a local TCP socket. This was grabbed a long time after start up. I also had the luck to grab one of the chunk-download connections through netstat in the fraction of a second when it was alive:

TCP 192.168.1.112:52495 178.79.251.140:443 ESTABLISHED
[vlc.exe]

Usually, the only one I see is the initial connection that has not closed properly

While doing this I had one of the rare occasions when the system stopped working. I checked with netstat and found the status of the initial connection had changed from CLOSE_WAIT to LAST-ACK. That means the player had decided to continue with the process of closing the connection as requested by the server an hour before. The player would have sent a "FIN" message to the server to say it had done with it. It would then wait for an "ACK" message from the server. It would not get it because the server would have abandoned the connection soon after telling the player it wanted to close it. That should not block the player from continuing, but maybe it is all in one thread and it does block. I think this may be the cause of failing connections. The browsers are probably using exactly the same library to do MPEG DASH as vlc. If the wait for the ACK times out, it may start playing again but if it has been too long it may no longer know what to ask for to start again.

[OldTechie]

Ah sadness - it's all gone!

[johnb]

Yes, it's a pity that the stream has stopped but we all knew it was only a pilot.

I do wonder whether the flac streaming will be pursued or abandoned. It's obvious that there are some in the BBC who would like to develop it, and after all the HD stream started exactly the same way (with a Proms live-only pilot). However, the website showed a disappointingly low number of people who bothered to rate the "Concert Sound" so it might be difficult for those in the BBC promoting flac streaming to justify its further development.

[Stunsworth]

The page is showing that just under twelve thousand tried it. I'd love it to continue, even if for copyright reasons it was only the live concerts. The sound quality has been superb.

[Sir Velo]

I was going to add that they must know how many hits the site has had. 12k isn't much and fewer than 2k "likes" is pitiful.

[Stunsworth]

I was going to add that they must know how many hits the site has had. 12k isn't much and fewer than 2k "likes" is pitiful.

Im assuming that the 12k is unique IP addresses, still not very many I agree.

[Gweefry]

I think that the quoted figures are probably unrepresentative of the potential audience. Access to the stream was limited to a specific browser from a non-standard part of the BBC website.

If the lossless feed is to gain traction (and I certainly hope that the pilot has indicated an interest) then it has to be integrated into the iPlayer site and also made available to the sundry other ways (NAS, etc) in which listeners nowadays access the media.

We should not pretend that this is at the forefront of audio technology - it gives us the same quality that CDs brought in 1982. The world has moved on and true hi-res (96/24) is now available for commercial streaming, not to mention multichannel.

Given the amount of investment into improvement in the quality of visual media, HD and recent 4K trials, it would seem appropriate that high quality audio should also be adopted as an option.