[Enhancement] Remote players (mpd maybe)

[GioF71]

Hello, would you consider adding support for remote players (namely the first I'd prefer is MPD)? I have been a C/C++ developer, I might help with the implementation (I would of course need some guidance). No worries if you consider this out of scope.

Thank you

[epoupon]

Hello! What do you have in mind exactly?

[GioF71]

I mean a per-user configurability for external players. For mpd for example, the configuration items would a hostname (defaults to localhost), a port (defaults to 6600) and optionally, down the road, a password (mpd is not secure anyway). Also a BASE_URL use to compose the URL might be needed as well. If at least one player is configured, the gui would show sort of selector (maybe in the style of spotify with its spotify-connect) devices so the user would have the chance to decide where the playback should happen.

[epoupon]

Oh you mean something similar to the subsonic's jukebox mode, but with a configurable backend, not only for "local" output?

[GioF71]

Exactly! I find the jukebox option very limited as it assumes that the server is also the player. Currently I achieve the result of playing to separate devices using upmpdcli (I have written the subsonic plugin), but upnp is limited compared to a full-blown web interface. For example, even assuming the subsonic api were more complete/extended, it would be very complicated (or at least very convoluted) to use something like your filter from a upnp control point.

[epoupon]

Ok, then I am definitely interested in this!

Some year ago, I even already made a proof of concept to make LMS locally output using pulse audio. I guess pulse audio is versatile enough to handle most use cases?

Making the web interface interact remotely with the "server's player" instead of the local html player is quite a big change too.

Bonus: what I had in mind was also to get rid of the ffmpeg binary dependency and use the libav directly to transcode files (lighter/faster than fork/exec using ffmpeg, and can also be easier to restore the acoustic similarity engine #301)

[GioF71]

Well PulseAudio is generally available on a desktop linux, while mpd can be installed in headless devices, much more similar to what hi-fi streamers are. Also PulseAudio is not bitperfect, it can be configured to use an alternate sampling rate on top of default 16/44.1 with compilicated configurations... it's not considered hi-fi afaik (just check around on the web about this topic). Mpd can use alsa directly and can guarantee the best possibile quality given the available hardware.

I understand that this is a big change but it's great to hear you are interested :-) If you can break it down to tasks, I would be happy to contribute somehow.

[epoupon]

But how would we control mpd from lms? What would be the data flow?

[GioF71]

Hello, well all the play operations should be executed to the select mpd device.

MPD has a client for C/C++ here, it should be available on distro packages also. It allows to enqueue, inspect the playlist and the current playback status.

So I imagine, if one has configured one mpd server using the LMS gui, and has selected it as the current player also using the LMS gui, when he/she clicks the "play" button on LMS, the playback should happen on mpd. The displayed album/playlist items should be added to the mpd play queue and playback should be started on the first or from the selected track. For each file, mpd should be fed with the corresponding subsonic stream url (or something similar if you don't want to make this feature depend on the subsonic api).

What do you think? Does it sound feasible?

[epoupon]

Using subsonic API, the url we would send to mpd would encode some auth info we cannot even generate (because passwords are encrypted using bcrypt). But we could generate session bound resources, like it is done for the current html player. I still feel the Pulse Audio way is more natural as PA is really a pure sound proxy (and you can do nearly whatever you want from it), but I have to dig a bit about the bit perfect things. Ideally we should abstract all the "local player" thing and plug whatever backend we want.

[GioF71]

Hello, I don't know a lot of pulseaudio used as a sound proxy, I will have a look at it. Another option would be to play to upnp/dlna devices, that would have the advantage of not needing some upfront static configuration

[dweymouth]

@GioF71 Are you familiar with how upnp/dlna casting APIs work? If so, perhaps you might be interested in helping add uPnP casting capability to Supersonic? :) It's been on my backlog for a long time and some exploratory work has been started but I still probably won't be able to get to it for awhile..

[GioF71]

Hello @dweymouth, sorry for the late answer. Unfortunately I don't have a lot of experience. My previous work in the area has been limited to building plugins for upmpdcli, which only require a portion of the knowledge about upnp, specifically the metadata that are relevant for the various entries that the control points can display (artist, album, song, etc.) But I would be glad to help, and learning upnp is something I have been wanting to do for a long time.

As a side note, did you try the subsonic plugin for upmpdcli? Of course this is not the same as integrating the UPnP functionality in a desktop app, but it's something. We can already stream from Subsonic (Navidrome, LMS, Gonic) to UPnP renderers with this solution.

Anyway I will let you know if I can learn enough for contributing the feature to Supersonic.

[barolo]

I don't remember which one now but I think Navidrome uses mpv/libmpv in jukebox mode to output sound and it's pretty much a dumb receiver with mostly automatic configuration.

[GioF71]

Hello @barolo, yes we know about this feature, but this request is different. The jukebox feature uses mpv/libmpv on the same host as the server. With this feature the objective is to be able to play to remote hosts.