-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does it support the Chromecast API? #2
Comments
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. |
That's a shame but there is some other reverse engineered examples I think? https://github.com/ajhsu/chromecast-device-emulator |
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. |
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. |
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? |
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. |
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. |
Yeah, I don't see this happening at all on the platform. |
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) |
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. |
Just came across this issue while searching for an Open Source Google Cast receiver. I have found this page: 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. |
Like can I just "cast" from all apps on my android phone?
The text was updated successfully, but these errors were encountered: