Apple chose to do the bare minimum in its integration into Sonos. Do not expect it to change whilst Apple are selling their own speakers. I tried Apple Music when I had a free offer and hated it for this and other reasons.  The Spotify and Amazon integrations are examples of what can be achieved. 

So you are saying, that Spotify switches from Airplay playback to stream directly from a speaker  automatically, but Apple Music won’t, and it’s a music app issue and not Sonos App issue?

If you are using Airplay, music is always passing through the phone/pad. SPOTIFY and AMAZON are more advanced and can play directly through the SONOS system. At that point the phone/pad can be shut down.

SONOS offers a free API that music services can use to play directly through the SONOS system, but developing the interface is the music service’s responsibility. AMAZON and SPOTIFY have taken advantage of this API.

@buzz

This can’t be the complete truth. Any app (including Sonos) can access an Apple Music subscriber’s library (if the subscriber permits it) by connecting directly to the Apple Music server.

That streaming does not have to go through any of the subscriber’s devices but can go straight from the Sonos speaker via WiFi to Apple’s Music server online and its API:s. That is entirely in the hands of Sonos. Why isn’t that used, especially since it’s the recommended way to do it?

In this way, Sonos could also easily provide a button for users who want to manually switch an Airplay streaming to “independent” Sonos streaming.

Actually, what you are saying is a bit of BS. Because Sonos is already today using this mechanism when you, from inside the Sonos app, initiate playing of music that resides on your Apple Music account. In this case, Sonos doesn’t use Airplay but gets the music straight from Apple’s music server.

At the risk of sounding confrontational: why should Sonos do that? If they do it for Apple, who else should they do it for? Will Spotify complain that Apple is getting preferential treatment? Surely it’s up to those companies to use the provided api if they want their service to run on Sonos? 

@nik9669a

No, you got it all backwards here. It’s entirely up to Sonos to offer connections to the rest of the world from their own app. Exactly the same way any other service from any other app is responsible for what external services it wants to connect. All the parts are there for Sonos to use, and it’s in their hands to 100%. Exactly as the author of this discussion topic has also realized already from the beginning (read the start of this discussion carefully).

I believe you may have mixed up the situation in this discussion for what functionality and services the Apple Music app should have, and that’s an entirely different question that doesn’t concern the topic of this discussion at all.

First off the Sonos app is just a controller. Things like search could be contained in just the app, but music playback, voice control, group coordination, etc, occurs on the speakers themselves.

If Sonos used a separate API for every music streaming service that it supports, then that would introduce a multitude of issues.  For one, the speakers have limited resources, and APIs, though small would eat memory rather quickly. This is particularly true for the older Sonos models, which still must be able to participate in streaming, but even resources on the new models are better used for other functions.  Music streaming services in the cloud have a lot more resources, obviously.

Then there is the issue of development and support efforts.  It is much more efficient for Sonos to deal with one single API rather all the different APIs other music services may offer.  Yes, that puts some burden on the music services, but also allows them to fix issues with an urgency they think is appropriate, rather than being dependent on Sonos.  Many of them may not even really have an API of their own anyway, so Sonos would have to provide an API to them.

Using a Sonos API also creates a fair marketplace for services. Each service can implement the features they want to represent their service within the API, without Sonos having to give precedence to one service or another. Customers can talk to the service provider to implement features, rather than Sonos having to weigh one service or another. This could also have some legal implications as well, since Sonos does not need to be concerned with presenting services according to the streaming services requirements, rather than their own.  Services rightly would want to make sure that using their own API results in a user experience they approve of, but Sonos holding the API means they do not have to hold to some other companies standards.

All that said, I wouldn’t be too surprised if Sonos makes exceptions for the larger streaming services like Apple, outside of protocols like airplay.  I doubt it, but wouldn’t be to surprised.

Regarding the casting ability you get with other services, Amazon, Spotify, Pandora, etc, those features will actually stop playback on your personal device (if already initiated), and move the stream playback to the Sonos speaker, or whatever you cast to.  It’s managed on the streaming services servers.  You don’t even need to be connected to your WiFi network in some cases. Airplay is different in that playback remains through the device when you transfer the audio to a Sonos speaker. In other words ‘ownership’ doesn’t transfer.  Apple may allow you to transfer ownership to a Homepod or AppleTV, I don’t know, but that would be a feature Apple uses to keep you in their ecosystem.

If this was your platform, this is the way that you would implement streaming from a service. This requires that you do all of the coding to play each service ABC, BCD, to XYZ. If, due to customer demand, you decided to add service RRR, you’d have a coding project to budget.

SONOS has turned this inside out from your vision by offering the API. Any service that wants join the SONOS family can do so by supporting the API. SONOS involvement is limited to checking that the service’s implementation works. Also, since all services use the same API, the presentation to the user is consistent.

Similar to other platforms that are SONOS competitors, your platform would offer a limited number of services because your coding project resources would be finite. Services would constantly be lobbying to come aboard. SONOS, on the other hand, supports many, many dozens of services because the service simply needs to show that it support’s the API. I have a friend who offers very specialized music to a small group of dedicated followers. He is considering supporting the API. There is no way that you would consider committing resources to support this small group of listeners.

It is a matter of perspective whether it’s the speakers that are accessing the music or the music services that are accessing the speakers. With smart speakers like Sonos, I tend to take the perspective of the speakers as central.

Also, there are probably 10,000 speaker models in the market but only about 5 music streaming services. This points the finger of responsibility to the speaker makers. And since all the tech is already in place, why whimper. Just do it, and gain some momentum for your business while tending to your customers’ interest.

When I ‘add a music service’ to Sonos here in the US, I’m presented with over 100 streaming services, not 5. 

Perspective is irrelevant.  It’s a two way communication between speaker and service using the API that Sonos built.  Therefore, if Apple wants to add the ability to swtich from Airplay, to playing on Sonos directly, they can write code to do that.  

Even  if the API uses was Apple’s I seriously doubt that Apple would allow a speaker to request playback of whatever’s playing on an airplay stream  midstream, initiated from a different app on a different device. 

This is just fiction.  Sonos supports 138 streaming services.     As far as the tech already being in place, Sonos existed long before an Apple music streaming services existed, and created their API, before Apple, or other streaming services really, even considering having playback outside of their streaming apps.  Your assumption that Apple is big, so they must have been first, is simply not correct.

Why is it always Apple users who refuse to believe anything is Apple’s fault, even when shown objective facts which place the blame on Apple?  It’s like a boss I used to have.  If anything in the software design clashed with his incredibly meager ability to understand software design, his standard retort was “Well, then it’s poorly designed.”  He’d rather cut off a limb than admit he may be the one who doesn’t know what he’s talking about. 

With Sonos-initiated playback the player is the master, whereas in AirPlay mode the player is the receiver/slave and the iThing sender the master.

It’s not just Apple users.  We see the same reaction with the integration between Sonos app and android, or the complete lack of chromecast support. There is even some cases where integration between Sonos and Amazon isn’t working and it’s assumed to be Sonos fault.

I think it may just be natural to assume that the bigger company dictates to the smaller company Sort of a ‘might makes right’ assumption.  That’s not entirely incorrect in some sense because a break in integration between a big tech company and Sonos will surely hurt Sonos more than the big tech...although probably not as lopsided as you’d think.

Perhaps it’s because Apple and others seem less approachable with their issues?  No one I can get Apple to fix the issue, they are too big to care, so I’ll complain to Sonos instead?

Personally, I see it more with Apple users, but I may be biased.  I’ve had people actually go lobby Google Play Music and/or YouTube when informed about the workings of SMAPI.  I’ve personally never seen an Apple user do the same, it’s always either “No, it’s Sonos’ fault” or “Why should I do the work, Sonos should lobby for me.”

And the reason for that is the Sonos Music API.  If Sonos approached this like Bose or Bluesound, they’d have less than a dozen (and sales for those units show it).  Seems like maybe Sonos is doing something right. 

It’s also ‘the last thing in the chain’ that is to blame, everything upstream must already be working perfectly, no?

Yet in other tech, people are perfectly capable of figuring out blame.  Nobody blames Samsung TV’s when the cable is out or Netflix is down.  So while your post may be human nature, there’s something else at work here.  I’m going with the Jobsian Reality Distortion Field.  

I think the argument who’s responsibility it is is not necessary. Both functions are already in the app. Streaming directly from (in my case) Spotify and stream through Airplay. The only thing that is needed is to add a button to switch from airplay to a direct stream, so you can shut down Spotify on your device and leave the building. Because Sonos is the only one who can change their app, this one is on Sonos its plate. Wkr Tysson

Sorry, but I do not think Airplay is “already in the (Sonos) app”. It is on your phone and in (probably) the app you use to play your music. The Sonos app is just a remote control, so it is illogical to assume Airplay is built into it.