Not the author, and I'm also not sure I fully understand your question, but am assuming 'cast or airplay' refers to the method used by mobile devices to redirect AV streams to different devices.
Both those solutions still require a spotify client somewhere to interact with the spotify api. The spotify client is still ultimately responsible for determining what to play, where to play from, and what stream URL then needs to be 'cast' to the device.
The box therefore running it's own client independently means you can still control it remotely, but it no longer hijacks control of all audio output on your mobile (or other) device.
spotifyd also implements the Spotify Connect protocol, which enables you to control it through the Spotify app (mobile, desktop, or web), while still retaining independent audio output for other apps on your devices.
This is true for AirPlay, but not really for Google Cast: While a Cast-capable device is required to initially launch Spotify, the Spotify Cast app is a full-featured Spotify Connect client.
For example, you can launch Spotify on a Google Home and control it from any device logged in to the same account, regardless of whether it understands the Cast protocol, is on the same network etc.
I suspect that once Spotify offers HomePod support, the situation might look somewhat similar for AirPlay (since being able to continue streaming with your phone out of battery etc. is possible on Apple Music on a HomePod already).
I kinda knew this since I think the feature you described is also available through Alexa/Echo, but I never really took the time to think about what was going on behind the scenes.
However, I'm still struggling to understand what is going on in your example.
When you control Spotify from your phone (volume++, next, new song, etc), how does Google Home know to do something?
When you tell Google Home "google play never gonna give you up", how does the Spotify app on your phone know how to reflect what's playing on the Spotify app?
Technically I can imagine that there is a shadow state of your Spotify instance sitting out in the cloud somewhere, but what are the mechanisms that make all this work together? Is this part of the "cast" protocol/architecture? Is this Spotify specific IP/tech that they can push on Google and Alexa to include on their IOT/smart services since they have the clout and pull?
Do you have any good links (not too technical, not too lite) on how this works?
> but am assuming 'cast or airplay' refers to the method used by mobile devices to redirect AV streams to different devices.
Yes, thank you for phrasing it better.
I don't think what you said is 100% true. I have an old chromecast that is capable of playing Spotify without the "spotify client" (i assume you mean spodifyd).
From what I understand about chromecast is that it uses a "cast protocol" (?) and therefore doesn't require "clients" (xyzd) for each media service integration.
Unsure about airplay though.
I imagine the reason they chose to use this spotifyd approach might be
- There is no "cast client" or "airplay client" available
- Audio properties of the Spotifyd client are superior to the alternatives
- They only use spotify
- just because they wanted to
Yup, i understand the idea behind these clients and why they're superior to bluetooth.
Both those solutions still require a spotify client somewhere to interact with the spotify api. The spotify client is still ultimately responsible for determining what to play, where to play from, and what stream URL then needs to be 'cast' to the device.
The box therefore running it's own client independently means you can still control it remotely, but it no longer hijacks control of all audio output on your mobile (or other) device.
spotifyd also implements the Spotify Connect protocol, which enables you to control it through the Spotify app (mobile, desktop, or web), while still retaining independent audio output for other apps on your devices.