Spotify device

[david_a_dawson]

Howdy.

So, following on from my foray into qOrbiter, I'd like to have a crack at a DCE device proper.   As I've wittered on at length about on the dev IRC, I'd like to make a device that can play spotify stream music and control it via qorbiter.

Before embarking on a coding adventure (some time later this month or likely in March), I'm gathering some information on what approaches to take. So, a few questions if anyone has an idea.

Spotify is based on user accounts.  I'd like to be able to have multiple devices to play differnt music in different areas, but that requires more than one spotify account. We have 2 accounrs, one for me and one for my wife.  So that fits into a device per user model, but I'm not sure if thats the best model.  You can't have a single user account in use by more than 1 device at a time.

My questions :-

• Where should this device live (core, media director), and should I have it being a device per user account?
  
• Might there be a way to have the device on the core, and expose the audio as a network stream?  If this is possible, it'd be cool, as then non media directors could tap into the stream, and stream could be played over multiple zones from the same device.
• Is there a preferred mechanism to output sound (eg, alsa, phonon etc)?  (although some networked solution does seem preferable...)
  
• This is going to need a UI in the orbiter.  I've no real interest in adding to the current orbiter, only qorbiter.  Given that, whats the outline of the process to add a totally new set of screens? small single numbers thereof. (feel free to RTFM me on this if there's an entry somewhere I haven't found yet)

So, any ideas welcome.

David.

[sambuca]

Hi,

I would put the device on the core if it does not really need to be on the MD.
I would always try to expose the audio as a stream, this allows us to seamlessly send audio to both squeezeboxes and MDs.
There is a spotify library iirc? Is that what you intend to use. Either way, it should be possible to implement several spotify clients within the same Spotify device, right? So it might not be necessary with several devices.

If possible, I'd use xine to play the stream on MDs, and then there be no reason for the spotify device to be on the MD itself. All of this is depending upon a spotify device that allows us to access the audio stream in some way, ofcourse.

Don't know the exact process of adding screens, but they need to be added in the Screen table in the database. I think this is used, at least as reference, in qOrbiter too.
After adding an entry in the table, and committing it to sqlCVS, you go ahead create a new Screen_xx.xml file in qOrbiter (from how I understand qOrbiter).

br,
sambuca

[david_a_dawson]

Hi,

I would put the device on the core if it does not really need to be on the MD.
I would always try to expose the audio as a stream, this allows us to seamlessly send audio to both squeezeboxes and MDs.
There is a spotify library iirc? Is that what you intend to use. Either way, it should be possible to implement several spotify clients within the same Spotify device, right? So it might not be necessary with several devices.

If possible, I'd use xine to play the stream on MDs, and then there be no reason for the spotify device to be on the MD itself. All of this is depending upon a spotify device that allows us to access the audio stream in some way, ofcourse.

Don't know the exact process of adding screens, but they need to be added in the Screen table in the database. I think this is used, at least as reference, in qOrbiter too.
After adding an entry in the table, and committing it to sqlCVS, you go ahead create a new Screen_xx.xml file in qOrbiter (from how I understand qOrbiter).

br,
sambuca

Yes, I'm planning to use libspotify.

Apparently libspotify delivers audio as PCM data.  I suppose that this will need to be converted to proper digital in some way and wrapped in some streaming protocol to make it network accessible (any idea?). 
hmm, sounds a fair sized task. Thats definitely my aim though, anything else seems weak.

On using xine.  I suppose that there would need to be some scenario set up that would startup the spotify stream and direct xine to play from that.  So the constraint on the network format is really what xine can consume (and what the squeezeboxes can support, and my ability to convert PCM data to a network stream, blah).
This is something I'm interested in, how would the architecture of that hang together?   I mean, on the orbiter I'd press a button that will trigger a scenario (I imagine) that will send a command to both the spotify device and a xine device on a particular MD.  Right?

I like the multiple accounts within a single device.  I'll work towards that I think.

If I wanted to direct the audio across multiple media directors/ zones, how would the scenarios work for that?

Sorry for mixing a few idiot questions in.  I'm still full of holes when it comes to how bits of the system work (learning fast though :-))

David.

[KlfJoat]

I'm not a LMCE dev (yet?), but I wanted to chime in because a) I'm VERY interested in a Spotify client and b) I think you're making it more complicated than it needs to be.

PCM *IS* digital.  And pretty much cross-platform.  It's used by CD's.  Look up PCM in Wikipedia for info. 

As for how to stream it, I would imagine the CD playback function of LMCE may be instructive.  

[sambuca]

It should be possible to send PCM data to xine. PCM data uses more bandwith, but not enough to justify converting it to something else. I also suspect that the audio has already been converted once from mp3 to PCM. Maybe there is some way to get the original data from libspotify instead of PCM?
The CD playback is just xine streaming audio from one MD to another, nothing special there.

Whether you need a scenario or not depends on your implementation and design. But a scenario button to open the spotify-specific screen seems to be the best way. From that screen, I would imaging that you can search and play tracks. The searching and playing part is what needs to send commands to the spotify device. When the spotify device has a stream ready, a MH_Play_Media command needs to go to the MediaPlugin to register the media stream in the system and direct it to the correct playback device. If you use the Streamed Audio media type, the MediaPlugin will automatically send the proper commands to xine.

So a first step would be to create a spotify device, with the required commands (at least search and play), and have it present a stream on some port when it plays. Then test this by issuing a manual MH_Play_Media command with the stream url. When this works, you can start looking at the orbiter screens.

br,
sambuca