Playdar as player and resolvers that require certain players

[stever]

Hello

Given that Spotify has it's own player, and reasons for having music
played that way rather than streamed via Playdar, this relates to
Playdar changes to allow for integration with this type of service.

JP has already outlined ideas along these lines in the previous
thread, and I agree we need to establish a music player daemon
alongside Playdar which is working alongside the resolvers to indicate
a specific player required, if any.

I figure that we already have limitations in a Flash player regarding
encoding formats, so if we can change the Playdar API to allow a query
to specify the type of results that are acceptable then we can also
integrate these local-only player modules. Clearly we would like to
avoid breaking changes to the existing API, and perhaps we can say
that if no type is specified in the query then it's meant to be Flash
compatible as is typical just now. Desktop players could integrate
better with other types of streaming service that require direct
access to the audio interfaces, as well as supporting other streaming
audio formats that Flash isn't supporting.

So far I don't think the changes to Playdar would do much to break
existing functionality, but I also believe we should be looking to
create a separate, and optional player daemon (no use if Flash web-
based players are all you are interested in). This would need to
manage simultaneous requests gracefully as JP suggested. It may be
more involved to get players to work well together and not tie up
resources, and allow for modules much like resolvers are in playdar-
core. I suggest we look at mpd for some inspiration and try to muster
something that will serve Playdar well in the task of controlling
multiple players. We could call it playdar-mpd perhaps. I do believe
it should be separate and allow Playdar core to be used as a pure
resolver daemon alongside. Perhaps, like mpd we could also integrate a
content library API.

I'm keen to develop skills in Erlang. I think that Playdar should
stick to Erlang as much as possible. I realise that there is already
work on a C++ library module but I would like to know if we could
merge the library and player daemon much like mpd, in Erlang, at the
highest level at least.

RJ, do you think we could form a new git project to pair with playdar-
core, combining a high-level player and library manager along these
lines?

I have used mpd a little and like the approach. I'd enjoy helping
build something like that and have it play well with Playdar would
make it great.

Regards

Steve

--
You received this message because you are subscribed to the Google Groups "playdar" group.
To post to this group, send email to pla...@googlegroups.com.
To unsubscribe from this group, send email to playdar+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/playdar?hl=en.

[Steve Robertson]

Maybe it should be more along the lines of developing the player module, however I feel there's a conflict of interest when Playdar allows you to resolve to distributed content, while the player is only playing content locally. It would also be good to see something like this more closely integrated.

[Steve Robertson]

Excuse me replying to my own post again, but thinking about this some more considering a user-friendly installer package, I think that it would be best to consider developing the player module to provide the playback functionality. Compatible with mpd if possible.

I've reduced the size of the Windar installer package, having combined Python resolvers and removed some more redundant Erlang files that it was still carrying. I really feel that it would be good to have a cut-down mplayer build in there too, as standard. I'm looking at this just now to see if I can remove redundant parts of mplayer (audio playback only required).

[JP Hastings-Spital]

I'm very keen for a player that's compatible with mpd - there are a fair number of mpd-clients out there already, plus the protocol for changing volume/tracks etc. is already well documented. It also brings what I think is a cool feature - playlists powered by playdar. There's a hundred ideas in that alone, but I shalln't pollute this thread with them.

Thinking about this a little more - what's to stop us using a modified mpd as the playdar player? I guess we'd have to work in support for some services (eg. spotify) but why reinvent the wheel?

[Lucas Gonze]

> Thinking about this a little more - what's to stop us using a modified mpd
> as the playdar player? I guess we'd have to work in support for some
> services (eg. spotify) but why reinvent the wheel?

Amen.

[Steve Robertson]

Well, if the wheel doesn't fit. Windows is not on the OS compatibility list for mpd.

[Steve Robertson]

Yeah, nice to be able to make this work with mpd players. Doesn't look like the API is complicated and it is documented.

I heard someone is looking at modifying mpd to resolve with playdar but I have no idea how that would work but it would be a cool ability for mpd. However, I don't believe that mpd would be built to work with different player back-ends, or easily modified this way because it is a player itself. We could use mplayer or gstreamer, and/or others, perhaps including spotify and others in headless mode through an abstraction. The mpd daemon is exactly the kind of thing I think we need, but probably not the implementation. There might be a Windows build for it in the future, and the lack of that is another concern.

I'm looking at mplayer, and I am able to build this on Windows removing optional modules. I'll hopefully make some significant file-size reductions as no interest in video currently. That's easier to get started with, but looking beyond that perhaps gstreamer would be a better choice for playdar regarding licensing as that core is LGPL and maybe it could be included as part of the playdar daemon. Anyway, this being pluggable is useful. Gstreamer looks complicated. Anyone had any experience with it?

[JP Hastings-Spital]

I hear you, but as you say it'd be great to have a bunch of tools out there already that work with it.

I guess what we really need is for playdar-core to have 'player plugins', one of which would be mplayer-esque (ie. could cope with 99% of common audio files), one would be 'web playback' which would send data to flash players (as it does now) and others  would be spotify type player/resolver plugins.

We'd then have 'control plugins' which would expose whatever API we like for the control of whichever player plugin is currently operating. One of these control plugins would be an MPD endpoint, so playdar could be controlled by the wealth of clients out there or any other control system we can think of (hey, with the exception of some irritating encryption, a control plugin might be able to work with Apple's Remote app for the iPhone - ie. playdar could pretend to be an iTunes library - this'd work really well with the new playdar library features I hear are being worked on)

The more I think about this the more I think it'd work really well to keep everything separate and modular like this — different platforms could have their own players, so we wouldn't need to worry too much when (for the sake of example) mpd is the better player for linux but mplayer is better on windows.

Sound any good? Am I talking nonsense?

[Lucas Gonze]

The control plugin seems unclear at the application level. I can't
picture where the seekbar and other standard controls end up.

[Steve Robertson]

Might be difficult to join it all up. However, once we can visualise how it could string together perhaps it won't be so much work.

Sure, mpd could be some kind of player plugin too, why not. Then I guess we'd need a resolver module for mpd also.

The way playdar provides streams is near ideal. It's only these other players like spotify that really require something different, though it would be nice to have an mpd-like service too, since mpd works well. Now I'm thinking that ideas surrounding library interfaces and playlists do belong elsewhere, and likely we could have player modules in Playdar to support those resolver results that require them. The resolver and player required must be linked. Rather than a playdar stream ID they might have some other identifier to be used, a play request id.

I'm probably thinking in too many different directions, and I'm also searching for some focus on this one topic as part of a bigger picture. Sometimes it's likely I am talking nonsense, but I don't worry too much - hopefully that's OK with others.

I am trying to see how additional streaming services could technically be brought on-board. I'm pretty much into the whole concept of an unbundled services and interoperability and different layers, common ground and innovation, but see Playdar in that position could be faltering due to this kind of thing. It's understandable that streaming services have some specific requirements to conform to their own licenses and business models. Users would choose their service providers according to their own preferences, which I expect is good considering the amount of choice and options there is already. It would seem important from an industry point of view, at least to the majority of interests.

There's some place in playdar-core for supporting multiple players, soon as possible. It would be good to know if indeed spotify was ready for this.

[JP Hastings-Spital]

I'm imagining the control plugin providing essentially the same functionality as the socket interface to mpd does, so the seekbar and player controls would be implemented in an external application (such as ncmpc, if the MPD control plugin were used, or the iPhone 'Remote' app if there was a suitable control plugin for emulating iTunes).

Essentially I'm suggesting that we *don't* create control applications directly (at least, not for now) but provide APIs so that others can create/use their own.

[Steve Robertson]

That's a very good point. This is another reason why the mpd type service could be important, then it probably needs to be part of playdar too. If playdar is playing and that's something we want, I believe. My thinking had been having some kind of control plugins with an mpd style controller as part of the playdar daemon, or as a separate but co-dependent daemon.

On Thu, May 13, 2010 at 10:29 PM, Lucas Gonze <lucas...@gmail.com> wrote:

The control plugin seems unclear at the application level.  I can't
picture where the seekbar and other standard controls end up.

[Steve Robertson]

Exactly. We would need to provide a framework and practical example for such plugins.

[JP Hastings-Spital]

Absolutely! New streaming services are bound to crop up and if playdar can accommodate them quickly then it'll always come out on top.

I'm going to break playdar down quickly into the features I see as being useful, shout if I'm missing anything, or going outside what's expected:

User Access Points

 - localhost:60210, as it is now, providing access to websites etc.

 - Would also provide additional APIs for direct control of (the current) player and playlists

Plugins

 - Resolvers

    Accept search terms, return unique identifiers for service / filetype / track uri

 - Players + Controls

    Each player can play any number of service / filetype combinations. eg.

    * mplayer: stream/mp3, local/aac…

    * spotify: spotify/spotifyReferenceId

    * streamproxy: stream/mp3, stream/ogg (this would emulate current playdar method)

    Players must expose basic controls to playdar: volume (get & set), play, pause, load track, position (tell & seek) 

 - Playlist keepers

    Will take any playlist source (local files, online XSPF, last.fm user library etc) and allow the user to query/modify/play through tracks from it. (access to spotify playlists, local .m3u files etc)

 - Monitors

    Upload listened tracks to Last.fm, keep local statistics, update twitter with your 'new fave track' etc.

Obviously some pieces of code would span several plugin types - spotify would be a resolver, player and playlist keeper. This method of organising everything allows playdar's current setup (the near ideal stream providing system) but also allows the addition of new streaming services that could be more cagey about licences etc.

I've never coded a large project so while I can see this kind of layout being great I can imagine that it could also provide problems. I do like the idea that 3rd party services could code their own plugins to support their new service on their own terms.

Tell me if I'm rambling too much here — I'd love to get some code down, so if any of this sounds reasonable I'll find something I'm capable of coding and get on it!

[Steve Robertson]

Magic. I'm also in the same position. I have dabbled a little in the code and I've been getting through the Erlang book, but I'm up for delving in further and trying to get some stuff to work along these lines.

While the playlists functionality would also be good I wonder about leaving that off completely for now, until later at least. The reason being it probably doesn't need to be done and might be handled external to playdar anyway. For example, mp3tunes library does not need to be interfaced by playdar, just resolves to it, and client is able to browse collection separately. This could be said for the others too. Perhaps it would be good to provide a common HTTP collections API sometime (already being formed by RJ perhaps, maybe as another application). It's not required in order to support specific players, as far as I can see just now.

Currently playdar provides a stream ID in it's resolver results. We would not be able to request a stream for some results so this is where the HTTP API may need to be changed, or augmented to provide results available on unstreamable sources.

There needs to be a new API to control the playback of those unstreamable sources. I'm inclined to see a single unstreamable result being linked to a single player plugin. Playdar does provide a player module already and I think that this is useful as an optional facility for the streaming sources. I think that another module would be required to manage a collection of players that handle certain unstreamable results, but they could share some common API and might be combined. For now it might keep things simpler if it were a new module specifically for a potential range of unstreamable results, specifically spotify if indeed that can be done, and others, or a mockup otherwise.

Having said that, perhaps the existing player module would be a good place to start, so far as developing a way to playback music (with feedback on track position and volume control as provided by mplayer in slave mode). We'd be looking at something similar for unstreamable sources.

I will try to spend some more time on further investigation and experiment a little. I firmly believe in incremental development, considering the wider picture, and focus on some smaller changes, moving constructively forward. At least it would be good to try some ideas and see where it goes. Feel free to pursue any of the above if it interests you, and certain you'll have more ideas too, which is cool. Good to be able to explore ideas here.

[JP Hastings-Spital]

I totally agree that we could attempt to take on too much at once and end up with little to show for it, but I think we ought to plan for a separate (/explicit) playlist API. Imagine Alice wants to listen to Bob's spotify playlist but she doesn't have a premium account (and doesn't want to hear adverts). She'll want to grab the playlist from the spotify service but have it resolve through other services. Conversely Bob's mp3tunes library might have amazing playlists but low bitrate tunes, so he might want to resolve them via his premium Spotify account.

I'm not sure how RJ is doing the library interface (ie. clients being able to query for all locally available tracks) but it seems to me that playlists are essentially just an expanded version of that; the 'local library' resolver currently provides a library playlist, other resolvers could provide their own.

As you say though, these playlists are a while away from being useful, so it's probably best going for the quick, small increment style of development.

To that end, where to start developing? I feel like I've been shown an ocean to swim in — I don't know where to start or which way to go really! I'm about 1/3 through the Erlang book, good with Ruby and assorted other not-so-applicable things, is there anything that particularly needs attending to? Is there a playdar to do list? Should we plan out the new/revised HTTP API?

Looking forward to the results of your experiments and investigations Steve — keep us posted!

[Steve Robertson]

Yeah, playlists are something I'm thinking about more in Playnode and you touch upon the exciting possibilities for working across various services there. I'm not against having a remote database with playlists at all either.

I've been spending some hours fiddling with mplayer ./configure options, and have managed to reduce the mplayer binary size by about 1/3. There appears to be some video drivers being put in with autodetect, and not controlled by configure options but might be a way to reduce the binary size a little more. So, I'm intending to bundle mplayer with Windar. All in all the installer file-size is under 15mb including the Python resolvers as executables, and mplayer, playdar and windar tray application. Perhaps a bit off-topic, but seriously, might think of using mplayer and playdar as the player daemon.

Being able to use mpd clients would be very interesting of course. It could be more of an extension to playdar, allowing playdar to serve some different purposes well.

More later.