headless / use as backend

[andrewrk]

I'd like to use this project as the backend for Groove Basin instead of MPD because MPD lacks many important things and has some critical bugs.

Is that on the roadmap?

[albertz]

It already supports headless playback.

The whole design is very modular - it's easy to add any further interfaces.

I already thought about adding a webinterface. I would have made it similar as the current Cocoa GUI. That isn't too complicated as most internal objects already have some extra information about how to display them in a GUI, e.g. how to layout them, etc.

I don't really know GrooveBasin that well - and even less about its internals. So I'm not sure how easy it would be to bind GrooveBasin and MusicPlayer together. But I would guess not too complicated. If you want to keep them both as separate processes and communicating via some network protocol, that also shouldn't be too complicated.

[andrewrk]

Ideally you would be able to control MusicPlayer via a socket connection. Is this on the roadmap? Would you accept a pull request which added the functionality? Do you plan on working on it yourself?

[albertz]

I often got people asking about a remote socket interface but until now no real reason for it, that is why I haven't added it yet.

I would be very happy to accept such a pull request. If you want to work on this: The main object/structure is the State class (State.py) which provides the basic functions (actually the GUI is automatically generated as a wrapper around this structure) or sub-objects (such as the upcoming queue or the current song) with further functions.

Or you tell me what interface you need, or what basic functions and I can maybe also add some initial code.

What about security? I.e. authentication? Encryption?

[andrewrk]

Here are the requirements of my ideal backend:

• Automatically handles ReplayGain under the covers. Does the scanning, volume adjustment, and switching between track and album mode automatically. Let me know if you feel like this needs discussing further - I do think backends should be able to accomplish this without user input.
• Ability to add songs to MusicPlayer's playlist by file path. I should be able to specify a UUID for playlist items so that I can issue further commands without waiting for a response, such as remove, move.
• Ability to toggle between Repeat One, Repeat Playlist, and Repeat Off
• Ability to Pause, Play, Stop, Skip Previous, Skip Next
• Ability to query for the current track status. Push notification when the current track status changes.
• Ability to change the volume
• Ability to group commands together so if I want to do 10 actions, we don't have to have 10 back and forth packets.
• Gapless playback
• httpd streaming. I should be able to configure MusicPlayer to serve streaming audio on a port so that I can choose to allow others to listen in.

@thejoshwolfe can you think of anything else?

Thanks for the tip about State.py. I'll see what I can do. First I want to check if you agree with all my requirements though.

For security, you could start by listening only on a unix domain socket. Essentially you use a file path instead of a port. This means that the file permissions apply to incoming connections. So you could limit the permissions to read/write only by the user id that runs MusicPlayer, and if I'm using you as my backend, then I'll just start you with the same user id as my own app.

[albertz]

• It already does the ReplayGain stuff. All under the hood and automatically. It has its own scanning algorithm built into the engine. It doesn't do the album-mode, yet, though (but only because it was not urgent for me to implement this yet).
• Adding a file to the playlist by path: state.queue.queue.append(Song(url=filepath)). You can try this yourself when you start it with the shell: ./main.py --shell

(I called it url because I thought of using arbitrary urls at some point. Right now, this is a bit untrue because they are just file paths and not urls.)

• The repeating model is not there at all but can easily be implemented. Except of skip previous, all other control functions are already there. Querying current song status is also there. As well as push notifications. As well as changing the volume.

It should be really easy to wrap all that over the network.

Gapless playback is not implemented yet but is my top entry on the TODO list for the player engine. Might take half a day to implement.

About the streaming: I was thinking about that too. But not sure yet about the best way. E.g. just also built it into the player engine - or add some interface and make it extern. Also, it currently uses PortAudio - maybe that already supports it? PortAudio does support PulseAudio - that very certainly has some output plugin for it.

[albertz]

Some updates here. There is a very generic remote control now in the socketcontrol module. It listens on a unix socket. It just can execute arbitrary Python commands. It executes them interactively (more or less like compile(.., "single")) and returns the result as a string-representation - just as the Python interactive shell does. There is also a client interactive shell implementation (for debugging and as an example).

This should give you all you need for controlling. Most of the API should hopefully stay mostly fixed - at least the basic stuff.

About the specific points you listed: Most of them are already there. But you might have specific questions about how to do certain things or you might want an easier way to do certain things, so I'm leaving this issue open for now.

[andrewrk]

Very cool. I'll share my findings once I get a chance to investigate.

[albertz]

Mostly for fun, I implemented a MPD backend (mostly incomplete but works). I even tested GrooveBasin with it and it works (somewhat).

However, I don't think that this is the way to go because the MPD protocol / MPD server has a somewhat different design which doesn't perfectly fit for this music player. For example, all of the playlist stuff is very different.

[andrewrk]

I decided to create a generic music player backend in C: https://github.com/superjoe30/libgroove/

It also uses ffmpeg (or rather libav) for audio decoding. Instead of replaygain for scanning it uses the excellent https://github.com/jiixyj/libebur128

Cheers mate and thanks for the help with this stuff.