Default media receiver. mp3 stream buffer too large.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use the CastHelloVideo example app, either with the hosted example receiver 
or the default media receiver.

1. Cast an MP3 stream URL, (eg Logitech Media Server stream, or a SomaFM 
shoutcast stream) to the default media receiver

2. Make a change on the server side of the stream, eg Change track, pause the 
stream 

What is the expected output? What do you see instead?
The output from the Chromecast receiver takes 70s seconds to reflect the 
change, suggesting that the audio buffer is much too large. I would prefer more 
like 5-10 seconds.

What version of the product are you using? On what operating system?
Chromecast 22062

Please provide any additional information below.
The html5 <audio> tag in Chrome (windows, v40) has a similar problem suggesting 
the buffer size is similar. I would like to see some sort of parameter 
available to adjust the buffer size, or for a much smaller buffer to be used 
for audio streams.

Original issue reported on code.google.com by julian.b...@gmail.com on 1 Feb 2015 at 12:21

[GoogleCodeExporter]

Sample stream. http://ice.somafm.com/groovesalad

Original comment by julian.b...@gmail.com on 1 Feb 2015 at 5:08

[GoogleCodeExporter]

This is a Chrome related issue. Its not on Chromecast side. Please feel free to 
report back if you come across a Chromecast specific issue.

Original comment by na...@google.com on 4 Feb 2015 at 6:28

• Changed state: NotSDK

[GoogleCodeExporter]

Well the stream is being played and interpreted in the Chromecast, not in 
Chrome and not just by casting the tab. So I don't see how it is a Chrome 
issue. I took pains to point out that the stream is being cast to the 
Chromecast using the example SDK app which is telling the Chromecast to load 
the media direct. If I use Logitech Media Server to check where it thinks it is 
streaming the audio, it shows the Chromecast IP address, NOT the laptop's, 
confirming that it's being loaded and decoded there.

There is a parallel issue in Chrome which makes me think the underlying issue 
is in the HTML5 implementation of mp3 stream decoding. It seems likely that 
similar code is being used in both places. However, I believe the issue 
described here absolutely IS a Chromecast issue.

Original comment by julian.b...@gmail.com on 5 Feb 2015 at 8:03

[GoogleCodeExporter]

If the problem I'm hitting is within the default media receiver, how is this 
not an SDK issue?

Original comment by julian.b...@gmail.com on 11 Feb 2015 at 1:51

[GoogleCodeExporter]

Two things:

1) This is a "Chrome related issue" because Chromecast is literally running 
Chrome (right now, Chrome M39, which you can determine by checking Chromecast's 
UA string).

2) I don't think the HTML spec provides for the application to set the 
buffering amount---IIRC it's quite the opposite, and actually specifies that 
the user agent itself should be handling the buffering when playing a media 
source by URL (e.g. an mp3 file, a video file, or a stream like you have). 
However, if you look into using MSE, it's the opposite: the user agent does 
_not_ do buffering, leaving it to the application to do its own buffering. We 
honor this on Chromecast. 

It looks like dalecurtis@ recommended a similar suggestion on your other bug at 
https://code.google.com/p/chromium/issues/detail?id=455619 .

Original comment by gun...@google.com on 11 Feb 2015 at 11:53

[GoogleCodeExporter]

Thanks for the explanation. As I said there, I think I may be confused by some 
Logitech  Media Server behaviour. I'll try and find something more reproducible 
and if necessary direct this at Chrome dev.

Original comment by julian.b...@gmail.com on 12 Feb 2015 at 4:09