If I hit a problem in the Default Media Receiver, where should this be report...

Julian Bond - 2015-02-11 13:56:20+0000 - Updated: 2015-02-11 13:59:06+0000

If I hit a problem in the Default Media Receiver, where should this be reported? I ask because I've reported a possible issue in the issue tracker, but this has been marked as "Not SDK".

https://code.google.com/p/google-cast-sdk/issues/detail?id=499

I guess this raises the issue of what is in the Default Media Receiver and if the source is available anywhere? For audio streams is it just a wrapper around the HTML5 <audio> tag? And does that mean there's the guts of Chrome running on the Chromecast implementing HTML5+Javascript and so my problem is really with Chrome and it's HTML5 support for <audio>?

google-cast-sdk

Charlie Fairchild - 2015-02-11 14:03:48+0000

The chromecast is basically just a chrome browser that loads webapps so that's why your bug was shot down as a chrome issue I think. I suppose you could open a ticket on the chrome browser tracker and it would move to chromecast if/when implemented. I don't know enough about the underlying stream/default receiver to know if they could add support for specifying the buffer size without a chrome change so someone else will have to speak to that.

Julian Bond - 2015-02-11 14:29:42+0000

OK. That makes sense. I've got a similar issue outstanding on the Chrome dev tracker. Thing is, I think it's a kind of esoteric and not terribly interesting issue.

It all relates back to wanting to be able to cast audio from desktop applications like VLC, Winamp, Windows Media Player, or iTunes. That led me to media servers like Logitech Media Server, Play To DNLA renderers, Shoutcast radio streams. I've hit some kind of brick wall on all of these. I'm kind of hoping that Cast For Audio will open something up along with VLC 2.2 which allegedly has Chromecast support. And Tunein may eventually get support for casting Shoutcast radio streams from desktop web.

At the moment, the html5 Audio tag is just a bit primitive for playing mp3 streams.

Jim Renkel - 2015-02-12 02:05:27+0000

Hmmm. I've had no problem with the <audio> tag being able to do anything I want, assuming the stream is in a supported encoding, e.g., mp3. I do have a custom receiver that has had some problems doing "tricky" stuff, but so far (knock on wood!) no problems with the audio tag.

In particular, repositioning the audio stream IN THE RECEIVER, i.e., setting the position attribute of the audio tag, is very responsive, usually only several seconds to buffer enough of the audio at the new position to begin playing. If anything, I would vote for a BIGGER buffer in the receiver. :-) BTW, you don't need to have a custom receiver to do positioning in the receiver, just a sender app that can send the right media control channel commands to the default or styled receiver. Many apps do this.

Julian Bond - 2015-02-12 09:59:51+0000

+Jim Renkel What kind of MP3 stream are you playing? Is it a shoutcast/icecast style continuous radio stream or a single mp3 file? I'm specifically interested in the continuous stream case. With this, positioning within the stream makes no sense (except possibly going back in time in the local cache buffer). You just want the stream to play as quickly as possible and to react to changes in the stream quickly so what you hear is in time with what's being sent. The only reason for a buffer between incoming bytes and played bytes is to protect against drop outs. So preferably <10s.

Jim Renkel - 2015-02-13 01:29:19+0000

+Julian Bond At this time my app does not yet support streams, only mp3 files. But simple experiments I have performed in anticipation of supporting them show no problems with doing so; they start up in a few seconds. Yes, repositioning a live stream makes no sense.