skip to Main Content
Crestron Sonos And Spotify

Crestron Sonos and Spotify

Ever since we finished our Sonos module for Crestron the same questions always come up:

  • “Does the module support Spotify?”
  • “Why doesn’t the module support Spotify?”
  • “When will the module support Spotify?”

Here are some things we came across that should answer all three questions.

First of all, let’s look at the Sonos product itself. Sonos uses standard UPnP, which allows you to  discover the device and communicate with it to establish functional network services. The most common use for UPnP is to render (i.e. play) individual items of content on a specific rendering device. A content playback scenario involves three distinct UPnP components: a MediaServer, a MediaRenderer, and a UPnP Control Point. These three components (each with a well-defined role) work together to accomplish the task. In this scenario, the MediaServer contains (entertainment) content that the user wants to render (e.g. display or listen to) on the MediaRenderer. The user interacts with the Control Point’s UI to locate and select the desired content on the MediaServer and to select the target MediaRenderer. Basically, you browse the Media Server for the URI of you track and then tell the MediaRenderer to play that URI.

A Sonos player actually performs both the tasks of a MediaServer and MediaRenderer. Any Sonos player allows you to add shared folders of content from anywhere on your network and will present these folders as a UPnP MediaServer. So instead of browsing a UPnP enabled NAS, the Control Point (for example the Sonos Software on your PC) browses the Sonos player itself. The Control Point uses UPnP to discover both the server and renderer capabilities in a Sonos player and establishes communication to use these services in order to browse and play content. Furthermore, in addition to playing one certain URI at a time, Sonos players are capable of managing their own now playing queue. So instead of the Control Point stacking up multiple URI’s and feeding them to the player one by one, it will trigger actions on the player for it to add and remove URI’s to its playlist.

That Control Point behavior is exactly what is implemented in our Sonos module for Crestron. The module auto discovers the UPnP MediaServer and MediaRenderer services within the Sonos player, browses the MediaServer for artists, albums, playlists an eventually tracks to come up with the desired URI’s and feeds these URI’s to the MediaRenderer to build up a now playing queue. Since the now playing queue is stored on the player instead of on the individual Control Points (i.e. the Sonos software and the Crestron module), when one Control Point adds a track to the playlist, the other Control Point is automatically updated to present the same queue.

For the Spotify integration Sonos handles this quite differently. In this case the browsing functionality is not presented as a UPnP MediaServer by the Sonos player itself, but instead is to be handled using services provided by Spotify directly. This means, that when in the Sonos software you select to browse through your Spotify content, the program is communicating directly towards Spotify to retrieve the desired URI’s. Once those URI’s have been successfully found, the Sonos software communicates these URI’s to the MediaRenderer service inside the Sonos player for it to build up a now playing queue in exactly the same way as it would with URI’s derived from you own library.

So, what exactly does Spotify have to offer for developers. According to http://developer.spotify.com, Two things:

  • libspotify: a C API package that allows third-party developers to write applications that utilize the Spotify music streaming service.
  • Web API: a series of ordinary HTTP GET messages which you may use to explore Spotify’s music catalogue.

While libspotify obviously enables developers to come up with full-blown Spotify enabled software (like Sonos), unfortunately it is not possible to implement such a library into a Crestron environment. So, we would have to go with the Web API.

The Web API provide us with two services:

  • search: to search for artists, albums or tracks
  • lookup: to gather more information about an artist, album or track

Unfortunately those two services, although together in theory sufficient to develop a module that browses the Spotify catalogue, lack paging functionality. You can search the catalogue for all artists and have them returned in pages, but there’s no (documented) way to alter the default page size of 100. Meaning that every search possibly returns 100 records which need to processed and paged through on the Crestron processor. If you would, for example, follow one of the examples documented in the Web API (http://ws.spotify.com/search/1/album?q=foo&page=2), you’ll get an xml feed listing the second page of the search result with the itemsPerPage parameter automatically set to 100.

The amount of data being passed back and forth for one such request, the processor time needed to process the response and the amount of information that should be stored on the Crestron processor, are to be handled very delicately within Crestron’s current programming environment to not overload the processor.  Also, paging of such information thus needs to be done in two ways: once to get 100 item pages from the Spotify services and then once more for showing those pages 8 items at a time.

There are three possible ways to prevent such challenges and streamline communication for optimal performance:

  1. Sonos implements the Spotify browsing on their player itself and have the player’s UPnP MediaServer present that as content just as it presents your own library. So the Control Points uses UPnP to communicate with the Sonos player and the Sonos player communicates with Spotify. I’m not familiar with the Sonos device architecture, though. It might well be that this is not feasible.
  2. Spotify expands their Web API to allow for more functionality, such as paging.
  3. Crestron changes their programming environment in such a way that you could implement the libspotify C libraries

In my opinion the latter would be ideal, but untill that day I’d be happy with a more elaborate Spotify Web-API.

Sources: https://developer.spotify.com http://upnp.org/sdcps-and-certification/

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top