Skip to content
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

Open
FutureSharks opened this issue Apr 7, 2021 · 11 comments
Open

Does it support the Chromecast API? #2

FutureSharks opened this issue Apr 7, 2021 · 11 comments

Comments

@FutureSharks
Copy link

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

@Jana-Marie
Copy link
Member

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
Copy link
Author

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
Copy link

Gartral commented Apr 7, 2021

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
Copy link
Member

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
Copy link

Gartral commented Apr 7, 2021

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
Copy link
Member

Manawyrm commented Apr 8, 2021

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
Copy link

Gartral commented Apr 13, 2021

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
Copy link
Member

Manawyrm commented Apr 13, 2021

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
Copy link

Gartral commented Apr 13, 2021

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
Copy link

blurpy commented Jun 26, 2021

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
Copy link

raress96 commented Jun 22, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants