All my music is stored on my computer, I don't use streaming services. The Sonos app is able to access my music and playlists, but using Alexa, all I can find are commands to access streaming services. How do I use Alexa to tell Sonos to access the music on my computer?
Page 2 / 2
However, when your players start playing something with the skill enabled, they tell the Sonos cloud what's on.
Is this something that was not happening till now? And has started happening only after the Alexa integration is invoked on Sonos?
And how does it do that. The reason why it can’t has already been explained. In great detail.
Nope. You are saying that. Sonos remains, as always, an excellent multi-room wifi speaker system. Your expectation of miracles is what is at fault.
Much of the above is well beyond my little brain. But as an end user I bought the dot and simply couldn't work out why it wouldn't play my local library. Not for one second did I think that functionality would not be present. I can't argue with the jargon, I can't argue with the figures for how much music is streamed but it most definitely stopped me going to buy some new sonos one speakers. The dot is now relegated to making fart noises for the kids.
It seems to me that the only way that the Alexa functionality will ever be able to fully control local music is if a copy of your local library index is also uploaded to the Sonos cloud for Alexa to access.
I'm personally not bothered if an index of my local music is stored on the Sonos cloud, and maybe there could be an option added to the controller app that allows the index file to be uploaded to the cloud once an indexing procedure is completed if the user wishes to have Alexa control for their local music.
Maybe a dialog popup explaining that to enable this feature will require the user to agree to their music index being uploaded to the cloud?
I'm personally not bothered if an index of my local music is stored on the Sonos cloud, and maybe there could be an option added to the controller app that allows the index file to be uploaded to the cloud once an indexing procedure is completed if the user wishes to have Alexa control for their local music.
Maybe a dialog popup explaining that to enable this feature will require the user to agree to their music index being uploaded to the cloud?
I have a limited Amazon music library from the few CDs i've purchased as gifts in the past. A few minutes ago with no music playing i asked Alexa "what is playing" and 'she' told me it was Get Back by The Beatles. This is the last thing I streamed using my Echo Dot.
My Sonos system has London Grammar's Love is a Beautiful Thing queued up but not playing.
I have 3 Sonos devices (Bedroom, Living Room & Kitchen) and one Echo Dot (also called Bedroom). In the Alexa app it has renamed the Sonos "Bedroom" device to "Bedroom Sonos" which is quite clever as it solves the naming conflict.
The system is currently set to play through all 3 speakers.
If i give Alexa the command "Resume music" The Beatles track resumes.
If I give the command "Resume music in (Sonos Device Name)" London Grammar resumes playing on all 3 Sonos Devices.
Now when I ask Alexa "what is playing" 'she' tells me its London Grammar. Interestingly the name Alexa gives for the album is "love is a beautiful thing ninth of June twenty seventeen". This is interesting because in my local library I have saved the album names with the release date at the end (because Sonos doesn't support release date searching) so the album is stored as "Love is a Beautiful Thing (09/06/2017)".
So Alexa is directly reading and interpreting the album name when I ask whats playing. This could be coming from the Sonos player cache.
If I stop the music and ask Alexa to "play London Grammar in the (room)" it says it cannot find music from London Grammar. So although Alexa seems to have access to the current Sonos queue and song data for the current track, it doesn't have access to the local library.
The functionality is very close to what i (incorrectly) expected - and I can start/stop Sonos using my voice which is great.
This isn't new information as the previous posts in this thread have mentioned most of the above, but I thought i explain how my system is working in case it helps clear up any confusion about whats currently possible.
My Sonos system has London Grammar's Love is a Beautiful Thing queued up but not playing.
I have 3 Sonos devices (Bedroom, Living Room & Kitchen) and one Echo Dot (also called Bedroom). In the Alexa app it has renamed the Sonos "Bedroom" device to "Bedroom Sonos" which is quite clever as it solves the naming conflict.
The system is currently set to play through all 3 speakers.
If i give Alexa the command "Resume music" The Beatles track resumes.
If I give the command "Resume music in (Sonos Device Name)" London Grammar resumes playing on all 3 Sonos Devices.
Now when I ask Alexa "what is playing" 'she' tells me its London Grammar. Interestingly the name Alexa gives for the album is "love is a beautiful thing ninth of June twenty seventeen". This is interesting because in my local library I have saved the album names with the release date at the end (because Sonos doesn't support release date searching) so the album is stored as "Love is a Beautiful Thing (09/06/2017)".
So Alexa is directly reading and interpreting the album name when I ask whats playing. This could be coming from the Sonos player cache.
If I stop the music and ask Alexa to "play London Grammar in the (room)" it says it cannot find music from London Grammar. So although Alexa seems to have access to the current Sonos queue and song data for the current track, it doesn't have access to the local library.
The functionality is very close to what i (incorrectly) expected - and I can start/stop Sonos using my voice which is great.
This isn't new information as the previous posts in this thread have mentioned most of the above, but I thought i explain how my system is working in case it helps clear up any confusion about whats currently possible.
It has been confirmed that Alexa is not querying the Sonos system on what is playing. The Sonos system pushes the track info to the cloud whenever a track change occurs and Alexa simply accesses that info. This was confirmed by someone playing a song, disconnecting their internet, then playing another song, reconnecting the internet, and asking Alexa what is playing. She replied with the song that played before the disconnection from the internet, not the actual song playing. This method does not lend one to think it can be used in any way to initiate play from a local library.
Was this always happening - this pushing - or has it started post Alexa integration?
Come to think of it, it must be new and the new privacy/consent agreement needed is probably related to this.
Whether it's new or not I don't know, but as I commented previously, if our local music information is being sent to the cloud then why not just send a copy of the local music data to the cloud for Alexa to use? I understand that it would mean if the Internet was down that voice control wouldn't work even with local music, but that's probably not going to be a common problem.
I guess the issue would be that Alexa would no longer just have one or two music databases to consult when looking for artist/track information, but also the individual users list of local music too.
I guess the issue would be that Alexa would no longer just have one or two music databases to consult when looking for artist/track information, but also the individual users list of local music too.
I believe if the Internet is down voice control won't work at all as voice recognition is done in the cloud.
I guess the issue would be that Alexa would no longer just have one or two music databases to consult when looking for artist/track information, but also the individual users list of local music too.
Huge difference between a single push of one track to the cloud, and building, maintaining, and updating an entire index of your library in the cloud. Then also building in the ways to search and access this cloud index in realtime fast enough for use. It is also a large amount of work on Amazon's part for no real benefit.
As an aside, I've been chatting to Google about whether this feature will be available on Google Home. They have confirmed they have received lots of requests for this functionality and whilst it isn't available at present, they are working on it but won't commit to any form of time scale. :)
Who knows what this actually means but with the option to switch AI's next year on the Sonos 1, it will be interesting to see if Google see this as a good USP against Alexa.
Who knows what this actually means but with the option to switch AI's next year on the Sonos 1, it will be interesting to see if Google see this as a good USP against Alexa.
Wish had seen this thread earlier. The fact that the Sonos cloud isn't just a pass through between the Alexa cloud and your local Sonos system is rather telling.
So I think the issue has to do with APIs. When a company puts out an API, it basically says 'this is how you will talk with our system'. It defines how data will be communicated in and out of the system. Before Alexa, Sonos had an API for controlling their system. They set the rules for communication. If an outside program wanted to tell Sonos to play music, Sonos defined how it needed to be done. If the program wanted to get info from Sonos (favorites or what's playing perhaps), Sonos defined how the request needed to be made.
Alexa has now come out with it's own API. It defines how it's going to tell a speaker system to play music and how it's going to ask the music system what's playing.
You can think of it as Alexa and Sonos speaking two different languages, and needing a translator in between. Sure, Sonos could be taught to speak Alexa language at the local level without the cloud. However, it has limited processing capabilities, and is already loaded with other tasks. Not to mention the fact that Google's going to have it's own API, it's own language, for Sonos to learn, so to speak.
So why does the index of local music need to be in the cloud? It already does this right? I can think of four reasons. One is the processing speed should be better in the cloud. You want to avoid a delay in making the command in Alexa and Sonos actually starting to play the music.
Two is that a search of the index is different then when done on the app. In the app, you return all results that fit the search criteria, letting the user pick what they want. In voice searches, you need an algorithm that returns just one value that best fits the search criteria, and just go with it. So there is little need to build this algorithm at the local level since it will only be used when called through the cloud anyway.
Three is that there may be other types of searches in the future. Alexa may choose to have a search where 3 top options are returned in the future, maybe displayed on the Echo Show for example. And Google could have a different type of search. You'll want to have the ability to have different search results depending on who's asking.
Fourth, whenever you need to fix a bug or add a new interface to the system, you don't want to have to require the customer to install yet another update.
So I think the issue has to do with APIs. When a company puts out an API, it basically says 'this is how you will talk with our system'. It defines how data will be communicated in and out of the system. Before Alexa, Sonos had an API for controlling their system. They set the rules for communication. If an outside program wanted to tell Sonos to play music, Sonos defined how it needed to be done. If the program wanted to get info from Sonos (favorites or what's playing perhaps), Sonos defined how the request needed to be made.
Alexa has now come out with it's own API. It defines how it's going to tell a speaker system to play music and how it's going to ask the music system what's playing.
You can think of it as Alexa and Sonos speaking two different languages, and needing a translator in between. Sure, Sonos could be taught to speak Alexa language at the local level without the cloud. However, it has limited processing capabilities, and is already loaded with other tasks. Not to mention the fact that Google's going to have it's own API, it's own language, for Sonos to learn, so to speak.
So why does the index of local music need to be in the cloud? It already does this right? I can think of four reasons. One is the processing speed should be better in the cloud. You want to avoid a delay in making the command in Alexa and Sonos actually starting to play the music.
Two is that a search of the index is different then when done on the app. In the app, you return all results that fit the search criteria, letting the user pick what they want. In voice searches, you need an algorithm that returns just one value that best fits the search criteria, and just go with it. So there is little need to build this algorithm at the local level since it will only be used when called through the cloud anyway.
Three is that there may be other types of searches in the future. Alexa may choose to have a search where 3 top options are returned in the future, maybe displayed on the Echo Show for example. And Google could have a different type of search. You'll want to have the ability to have different search results depending on who's asking.
Fourth, whenever you need to fix a bug or add a new interface to the system, you don't want to have to require the customer to install yet another update.
I do find people's view of what a Cloud can do quite interesting. You get what you pay for, and if you pay well, you get fast dedicated servers. However, add in the complexity of getting data from your local Sonos system to some remote servers somewhere else, collating all the information with everyone else's and then providing quick and timely searches of your library buried in there, and there's no real logic to say it should be any quicker than coming up with a different architecture. It's far more likely that the Sonos remote servers will get swamped and be slow, it's not like Sonos get more money from existing customers to fund storing all our music library indexes and song locations, making it highly available in multiple locations just in case they have issues and then making it available 24x7. Perhaps some nice intelligence to co-locate your data on Amazon AWS servers close to your actual location to make network latency a little less traumatic.. after all, requests from the UK being processed in the US will be subject to a few laws of physics that Scotty was always keen to remind captain Kirk you were unable to change... 🙂
Even the recently released Amazon Alexa-enabled smart groups took several days to propagate around Amazon's own servers before they could flick the switch and turn it on, so these things aren't instant.
I don't think our local libraries would be that hard for Alexa or any other remote service to query if there was a service available to query. There simply isn't. That's not to say Sonos can't create one, it just needs to fit onto a piece of Sonos hardware. I'd even be open to replacing an existing Sonos component with a souped up one that ran this service if that's what it took and it's beyond existing ones.
As far as I can tell, existing Sonos API's just expose the interface for streaming services, not Sonos control, this has always been done by the various controller apps and it's these that actually interface with the streaming services via these API's and present the information in unified way that the app can understand. It's good stuff and a good reason why Sonos has such good coverage of many services. (The latest Sonos announcements appear to finally open up the control side, but that's very new)
I think the problems Sonos have to overcome aren't just related to local libraries. At present there are really just two services on offer, and these seem to be of the simpler constant stream variety, and not the more complex queue-able type, hence people just see an Amazon music stream playing through the controller app, and not the queued list of music they are used to.
This will IMO almost certainly be down to that type of stream being the easiest to get going as for TuneIn it's just a simple stream, and for Amazon they can build a stream to send to Sonos themselves.
However, once more than one service that can search tracks is supported we will need some level of control over how the results get used... And that's all going to have to be done in the Sonos part of 'the cloud' because Amazon won't give a you know what about other services and collating their search results. Spotify support will be interesting here.
Presumably those settings will need to be in the Sonos skill for Alexa, and it will complicate the interface to Amazon Music, as they'll need to send individual results in a queue-able format to mix with results from other services.. else we'll be limited to selecting which services results stream we want to start playing.. One of the current controller app's strong points IMO is you get results from all your services and you get to pick and choose.
My criteria for choosing would be local first as it's the best quality, then I'd want the highest quality streamed version available.
However, if I said to Alexa/Google/Siri, "shuffle U2", and I'm subscribed to Amazon Music, and a couple of other services as well as having U2 on my local library, do I want lots of duplicates? Can Sonos filter out lower quality duplicates? How about play me U2 between 1980 and 1984? Is everyone's metadata up to scratch?
Interesting times ahead I feel, but I remain unconvinced that all-remote processing is the best way forward personally.
Even the recently released Amazon Alexa-enabled smart groups took several days to propagate around Amazon's own servers before they could flick the switch and turn it on, so these things aren't instant.
I don't think our local libraries would be that hard for Alexa or any other remote service to query if there was a service available to query. There simply isn't. That's not to say Sonos can't create one, it just needs to fit onto a piece of Sonos hardware. I'd even be open to replacing an existing Sonos component with a souped up one that ran this service if that's what it took and it's beyond existing ones.
As far as I can tell, existing Sonos API's just expose the interface for streaming services, not Sonos control, this has always been done by the various controller apps and it's these that actually interface with the streaming services via these API's and present the information in unified way that the app can understand. It's good stuff and a good reason why Sonos has such good coverage of many services. (The latest Sonos announcements appear to finally open up the control side, but that's very new)
I think the problems Sonos have to overcome aren't just related to local libraries. At present there are really just two services on offer, and these seem to be of the simpler constant stream variety, and not the more complex queue-able type, hence people just see an Amazon music stream playing through the controller app, and not the queued list of music they are used to.
This will IMO almost certainly be down to that type of stream being the easiest to get going as for TuneIn it's just a simple stream, and for Amazon they can build a stream to send to Sonos themselves.
However, once more than one service that can search tracks is supported we will need some level of control over how the results get used... And that's all going to have to be done in the Sonos part of 'the cloud' because Amazon won't give a you know what about other services and collating their search results. Spotify support will be interesting here.
Presumably those settings will need to be in the Sonos skill for Alexa, and it will complicate the interface to Amazon Music, as they'll need to send individual results in a queue-able format to mix with results from other services.. else we'll be limited to selecting which services results stream we want to start playing.. One of the current controller app's strong points IMO is you get results from all your services and you get to pick and choose.
My criteria for choosing would be local first as it's the best quality, then I'd want the highest quality streamed version available.
However, if I said to Alexa/Google/Siri, "shuffle U2", and I'm subscribed to Amazon Music, and a couple of other services as well as having U2 on my local library, do I want lots of duplicates? Can Sonos filter out lower quality duplicates? How about play me U2 between 1980 and 1984? Is everyone's metadata up to scratch?
Interesting times ahead I feel, but I remain unconvinced that all-remote processing is the best way forward personally.
However, when your players start playing something with the skill enabled, they tell the Sonos cloud what's on. So when you ask Alexa what's playing, the command goes to our cloud which looks up that room and what was last "advertised" as what's on. So if you're playing local tracks, the metadata for what's on is entirely dependent on what you called the track at home. Alexa and Sonos don't actually know what's on. They just have an artist name and track name. So if that track has no metadata, or bad metadata, you'll probably get some funny results.
Except this all seems to stop working when you have a pair of One's in a stereo pair. Since the first time I streamed anything from TuneIn, Alexa and Sonos no longer have any idea what's playing when we are listening to local music. The system will also not stop, pause, skip or anything else on either TuneIn or local music. Alexa just claims that there is no source playing so she's powerless to help.
TBH, I had expected a lot better even though I accept this is early adopter days.
The really annoying thing is that you can index your itunes library.xml through the My Media skill for Alexa. When you ask Alexa to play one of your songs she'll even go as far as saying 'playing [insert song name here] from your My Media collection'. So Alexa can obviously 'see' the xml file but guess what.......Sonos does not support the Audio Player API interfaces needed to play My Media, so I simply don't accept that this is technically difficult for Sonos, all the heavy lifting has already been done!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.