Esther,
I’m aware of this workaround. I have been using it. There are a lot of problems with it, unfortunately.
Wifi signals are never perfectly reliable. When you cast your phone audio with the Google Home app, the phone connects to your Plex server over Wifi once to get the audio - that’s one stream going over Wifi.
Then, your phone streams the phone audio to the Chromecast device over Wifi - that’s a second stream going over Wifi. That’s the best case.
If your Chromecast device is using Wifi, then you have a 3rd stream going over Wifi. 7 of my Chromecasts are wired to the main network. 6 are using powerline ethernet (better not turn on my induction cooktop when I use those!). 1 is using its Wifi chip. 1 is using ethernet but connected through ethernet to the a wireless AP.
In my very large home, some of the access points are wirelessly bridged as I don’t have ethernet plugs around the house. That will double the number of steams going over Wifi, and adds latency as well. One AP is even bridged wirelessly twice, ie. it’s connecting wirelessly to another AP, which itself is connected wirelessly to another AP. So, that actually triples the number of streams going over Wifi. In the worst case in my house, there can be as many as 7 data streams going over Wifi just to cast audio once.
The more streams go over Wifi, the more potential there is for latency to be added, or the connectiion to be dropped between the phone and CC device (“your connection to speaker XXX has ended”). And if it’s not dropped, you’ll get very unpleasant audio artifacts or delays.
A few weeks ago, I had a party with about 20 people at home. When people moved around the house, it changed the direction of the Wifi signal and caused hiccups with the audio.
Also, yesterday, I was in my hot tub for a bit. The phone overheated in the California sun after just 8 minutes and it closed most of the apps as a result. All audio stopped as a result. I was using the hot tub’s bluetooth speakers at the time but it would have been the same issue if I cast device audio from the phone to a Chromecast hooked up to an AVR powering up the speakers nearby on the deck.
And of course, if the (waterproof) phone falls it into the water, radio signals stop working, be they Wifi or Bluetooth.
If true casting was going on, the music would have kept going from the music server to the Chromecast - I would just have lost the ability to control it from the phone when it overheated (pause, change volume, etc).
I’m starting to regret the bad old days of having a CD changer hooked up to the AVRs instead of Chromecast, and using an RF remote that never overheated. Except those have failing mechanisms too, and I now have a stack of useless CD changers that need new belts or new lasers, and no one to fix them …
Even with 5 access points, Wifi is still in perfect in my house because there is extremely strong wall insulation for sound, which weakens Wifi signals. I would need to run more Ethernet wiring to directly wire all the APs, but this is simply too expensive.
The original Chromecast design involves at most 1 audio stream going over Wifi - the server on the internet pushes data through your internet connection, and then your Chromecast receives it through Wifi. Your phone is normally only used as a controller to start/stop the audio media. And you have the option to wire your Chromecast via Ethernet, making it 0 data stream going over Wifi.
Ideally, Plex Media server should be able to directly push data to the Chromecast as a stream as well, which would enable gapless playback. Unfortunately, it doesn’t. Neither does JRiver Media center server. Even if you use BubbleUPNP, you can push files, but not a gapless stream. I am not sure where the fault lies. I think most likely with Google not opening up their SDK enough.
I really feel like we are back in the bad old days of DOS where each piece of software had to have its own code to access each local audio device like a PC speaker, Sound Blaster, Ad Lib, etc. I wrote such code in the early 1990s. Then Windows and other operating systems came around and added an abstraction layer and an API every application could use, and it mostly solved that problem. We need that problem solved for networked audio devices too. Unfortunately, vendors try to sell their hardware and haven’t standardized on any protocol, and there is no API or SDK you can use to stream to any device. It’s a real shame. So, we are stuck choosing different music apps if you use Amazon speakers, Google chromecast devices, Sonos streamers, Denon/Marantz receivers, Yamaha receivers, etc.
