MiczFlor / RPi-Jukebox-RFID

A Raspberry Pi jukebox, playing local music, podcasts, web radio and streams triggered by RFID cards, web app or home automation. All plug and play via USB. GPIO scripts available.
http://phoniebox.de
MIT License
1.41k stars 398 forks source link

Podcasts and other players on future3 #2116

Open pabera opened 1 year ago

pabera commented 1 year ago

There are several threads and discussions about streaming services on the Phoniebox. Specifically Spotify has been requested multiple times. In V2.x, Spotify was implemented through Mopidy, a media server build for Raspberry Pi usage. It is essentially an opponent to the Phoniebox software. Alongside the MPD player, Mopidy was installed when users required Spotify support. Lot's of wiring had to happen in order to show the progress of the player as well as the RFID set up to it. Through plugins, Mopdiy can be extended.

For future3, we decided to completely rewrite the Phoniebox and the Webapp, which works pretty well. But we don't have third-party services support. To achieve that, a few things are required.

  1. future3 has a single player class, which is tightly wired to MPD. In order to support other players (regardless whether they are streaming or bare podcasts), the player class needs to support multiple players.
  2. A library needs to be implemented to manage the individual audio sources, like podcasts or streaming services. The question is, do libraries exist to implement them?

Installing Mopidy simultaneously to get streaming service support is counterproductive, as it will reduce the performance of the Phoniebox drastically. Otherwise, maybe it's a better approach to rely on such music servers rather than building some proprietary.

Since this is a big investment, I'd like to prevent individuals to move on and just publish a PR. I'd like to use the thread to discuss options and options going forward and then some people can commit to build it going forward.

Thoughts?

s-martin commented 1 year ago

I think a "plugin audio system" could be a nice approach, i.e. each audio source is a plugin. This would mean that we would need to design an architecture and probably provide 1-2 "reference plugins", e.g. MPD and Spotify (which is probably the most popular).

For that we need probably dedicated owners/maintainers for each plugin.

s-raeuchle commented 1 year ago

I like the plugin idea and I think a Mopidy Plugin is not the badest thing...because you are able to choose. If People do not care about Performance, let them listen to music using heavy Mopidy.

If someone writes a better plugin, people will just switch. Tidal e.g. started now an official web api (beta without playback) https://github.com/orgs/tidal-music/discussions

Not sure what it takes to implement a plugged Audio Source, especially if you have enabled multiple audio sources.

A Interface would be very nice, so everyone is able to follow the plugin audio source standards.