Does it support the Chromecast API?

[FutureSharks]

Like can I just "cast" from all apps on my android phone?

[Jana-Marie]

Sadly the "cast" protocol used by google is not open source nor is there any compatible open source software. It is not supported, so no.

[FutureSharks]

That's a shame but there is some other reverse engineered examples I think?

https://github.com/ajhsu/chromecast-device-emulator
https://github.com/vbaicu/mMusicCast

[Gartral]

That's a shame but there is some other reverse engineered examples I think?

https://github.com/ajhsu/chromecast-device-emulator
https://github.com/vbaicu/mMusicCast

I'm just doing my toes into the otter cast project, so this is a high level skim of the above projects. At first glance it appears that mMusicCast is closer to what you're looking for, but I have serious missgivings about trying to shoehorn a full electron app into 128mb of RAM.

I'll profile MMC later today and update from there. If it fits, this might be as simple as bake it in and turn it on.

CDE isn't suitable at all from their own admission of having to previously have a cast "sink" and basically doing a replay attack to force an app to talk to the server. Seems like it's more geared for hacking together your own castable apps rather than using it as a legit sink.

[Jana-Marie]

Thanks @Gartral! As a sidenote, MMC does not seem to be a "cast" receiver, it is just a spotify and youtube receiver. We already support spotify, so this does not add alot.

[Gartral]

Yea, MMC is only a partial implementation of the Cast/mDNS protocol. From what I can tell so far, Google Cast is a "closed ecosystem, with an open door". I popped the $5 to poke around in the google Cast Dev SDK site and I see an option for making a new receiver. Now, if my understanding of mDNS and the Cast Protocol works, we aren't exactly piping audio straight from one device to another, as we are requesting the cast receiver to go find what we asked it to play and just play it, on it's own.

In short, while it DOES look like we can implement Cast Audio on the ottercast, this will incur a running cost as we're going to need a publicly accessible server to "bounce" off of, and is partially reinventing the wheel for the project as Cast appears to be a loose collection of apps that all agree that Cast is an acceptable user agent, more than it is just a direct pipe. It's possible to implement, but the question is; Is it worth it? And worth how much?

[Manawyrm]

publicly accessible server
-- running servers is no issue, we have more than enough infrastructure at hand.

I'd like if that infrastructure could be self-hosted, though, to avoid shutting down people's OtterCast when our servers go down.

I'm personally using no devices capable of sending the Cast protocol, but would still be interested in implementing the feature.
Can you assess whether that server would actually need to transport any media data or just handshaking/API calls?
I'm guessing this would require some serious development time, though :/

[Gartral]

Sorry! my laptop was down for a few days (keyboard died). As far as I understand it, the Cast protocol doesn't stream the data itself from device to device, but the server is needed as a common reference point to do NAT walking and handshakes. The dev work, after digging into it, doesn't look like it's insurmountable but it WILL require shoehorning a "minified" Google Chrome browser into the OtterCast.

And I know from experience that the google home mini speakers can be used with some specific software on Linux as a target for pulse, but the latency is absolutely atrocious, on the order of seconds. The best I've been able to get is 3-4 seconds behind a youtube video. The average, without mucking around with a lot of networking first, is closer to 10 often north of that. And while I haven't looked directly, I suspect part of that is the handshake, I'll dig more into it.

In short: I don't personally see it as a good alternative to the other capabilities that the Ottercast has built in. It would only really be usable to cast audio from a phone to the OC.

[Manawyrm]

require shoehorning a "minified" Google Chrome

Yeah, I don't see this happening at all on the platform.
With 128 MB RAM (half of it is already used) and the rather slow 32bit ARMv7, running any kind of CEF, WebKit, Chromium, etc. is pretty much out of the question.

[Gartral]

64MB of ram is... doable. It'd be tight as hell, don't get me wrong, but it may well be doable. The original Nest Mini had a Synaptics AS370 with 256MB of ram.

Of course, the latest gen is the Home Mini with a Marvell 88DE3006 and 512MB of RAM. But if we're too clever by half, and disable a bunch of features when we're in "Cast mode" then we might be able too eek out a usable experience. This again wraps back around to my original point of "How badly do we want this?". if we're careful and manage it right, it might be doable.

I'm looking into how much of the Nest/Home's ram is used by the "os" and there isn't a lot of info there. But I suspect the actual usage for Cast/mDNS isn't too far off our target (Keeping in mind that the google devices have so far, to my knowledge, never been hacked and firmware dumped)

[blurpy]

How badly do we want this?

I've been looking for an alternative to the Chromecast Audio for years, so I dread the day my old one dies. Google only wants to sell speakers, and the other options are usually quite expensive and big.

I don't know if it will work on the current generation of hardware or not, but making a device that accepts casts from any audio app on Android is really useful. And even better if it supports toslink, for a full Chromecast Audio replacement.

[raress96]

Just came across this issue while searching for an Open Source Google Cast receiver.
I presume this is not going to be implemented any time soon right?

I have found this page:
https://developers.google.com/cast/docs/web_receiver#default_media_web_receiver

Which suggests that building a Google Cast receiver is possible, and I don't see it requiring a server, at least at first glance. Will have to look further into it.

[phaidros7]

Actually 2 questions:

Maybe I am on the wrong foot here and even be reanimating a corpse of a feature request .. but for the sake of having a dozen Chromecast Audio Devices in my home and in the desperate search for suitable wifi enabled sink devices (turntable!), I came across Otter :)

All Otter Chromecast Audio compatibility related docs lead to this ticket.

I understand that Chrome on the device is to bloated, but I am using mkchromecast rather successfully from my linux clients and wonder, if that is something the Otter is maybe capable to run:

https://github.com/muammar/mkchromecast

If so, would it be useful to incorporate?

My second question is: was there any approach to Google if they might open up the Cast protocol already? What would be a way to address that with them?

I'd love to see and support a solution with which the old Chromecast Audio Devices are given a way longer live.

[Manawyrm]

I understand that Chrome on the device is to bloated, but I am using mkchromecast rather successfully from my linux clients and wonder, if that is something the Otter is maybe capable to run:

Isn't this the wrong direction? This looks like it's a tool to stream audio TO other Chromecast devices.

[phaidros7]

I understand that Chrome on the device is to bloated, but I am using mkchromecast rather successfully from my linux clients and wonder, if that is something the Otter is maybe capable to run:

Isn't this the wrong direction? This looks like it's a tool to stream audio TO other Chromecast devices.

Nope, it is actually what I am looking for: an open source software/hardware bundle to use as a source for my network audio, and for now the sinks are Chromecast Audio.

I understood otter to be able to get a line signal and distribute it to the other otter devices in the network, is that correct?