Implement IPC for 3rd party applications.

[sashahilton00]

As librespot is looking to replace the libspotify_embedded libraries, it needs to be useable by external programs. The external program needs to be able to access information such as the following:

• Current Track Metadata
• Queue Metadata
• Playlist Metadata
• Current Track seek position
• Shuffle/Repeat enabled
• Next Track
• Is Device Connected
• Current Volume

I'm sure there are many more that could be implemented over time, but above are the few which seem to be fairly crucial.

N.B. PCM data is not included in the list as this issue is essentially suggesting that librespot ought to have an IPC implementation for access to various metadata.

[NeoLegends]

I'd very much appreciate this, especially if access to the audio data is provided. :+1:

[psych0d0g]

i would not provide easy access to the audio data via API to prevent piracy and fear of spotify closing down this project.

[sashahilton00]

I wouldn't worry about that too much, as there are plenty of spotify rippers and libspotify provides PCM anyway. The one thing i would siggest is keeping the cached songs encrypted, but for audio just piping it to /tmp/lrsaudio or something when playing shouldn't be an issue

[NeoLegends]

i would not provide easy access to the audio data via API to prevent piracy and fear of spotify closing down this project.

Don't get me wrong on that, I'm all for paying Spotify. However, access to sample data is required if you need to mix sounds from multiple sources together, do audio visualisations or crossfades / seamless playback.

The one thing i would siggest is keeping the cached songs encrypted

I'm not really sure about this. If we get PCM data while playing anyway, why keep the tracks encrypted on disk? It pretty much doesn't make a difference whether I use the decrypted MP3s or the PCM from the lib. Both are accessable only if I have a paid subscription, as far as I understand.

If there is a legitimate need to obfuscate the source tracks, I suggest going for a more practical approach: remove the extensions from the MP3 files and put them into folders with SHA-hash-names (Just like libspotify does). This should prevent most people from massively ripping tracks while librespot doesn't have that much to do to find cache entries.

[NeoLegends]

The new modular audio sink API should make implementing custom sinks (or receivers of audio data) pretty easy.

[sashahilton00]

The only reasonI thought encrypting tracks when stored is so that one can argue that it is only designed for streaming. Realistically one should never send someone content without expecting them to download it, but this isn't the view Spotify takes, as evident from the arcane encryption routines they use for their communication protocols, and the fact that songs on the desktop are encrypted, etc. It is more of an ass covering measure than an actual preventative

[NeoLegends]

Gotta love the manager who decided that, eh? 😂

Anyway, I see your point, this is probably the right route to take if this library was to provide access to audio data. It'll be easier if someone from Spotify tries to take down or take over this project.

[NeoLegends]

Are there any updates on this?

[plietar]

@NeoLegends to be honest I'm not too sure what this issue is about.

If it's for librespot to be used as a library by other rust programs, then it's already the case. You can add it to a Cargo.toml and use it. The API isn't very clean and might change a lot though.

If the issue is about bindings for other languages, the first step is to write C bindings, and then wrap that in whatever language. There's a shim of that in capi, which tries to expose the same interface as libspotify, but I haven't work on that in a while.

If the issue is some IPC based external API like spop then no, there hasn't been any work on that. I know the Volumio guys are interested in something like that.

That being said, I'm on holiday and will be in exam soon, so don't expect many updates for the next 2 weeks.

[sashahilton00]

Updated the title and original issue to clarify what I was talking about. In light of the apparent upcoming libspotify demise, it would be good if we could get some sort of IPC so that there is a maintained alternative to libspotify. I have a very basic JSON-RPC server that uses librespot as a library in a similar fashion to the spotsync repo. @plietar not sure if you are getting notified on Gitter anymore, I can continue this as a separate project if you would rather not bundle IPC with librespot, or equally I can try and build one into librespot, though at this point I am uncertain as to whether you have some sort of IPC planned or if you would rather keep to librespot including spotify related features and no more, in which case I'll write the server to use librespot as a library.

[allquixotic]

The idea in my head (or the itch I want to scratch) is taking some existing music player GUI -- any one, really, but I like Rhythmbox -- and implementing Spotify playback support via librespot. I'd also need to obtain the raw PCM bytes to pipe it through Rhythmbox's output system (Gstreamer) and provide support for plugins that touch the sound pipeline, like EQ, visualization, and (what I really want) pitch shifting, through, e.g. the rbpitch plugin for Rhythmbox.

There's a reasonably popular app on the Apple App Store that does pitch/tempo shifting and integrates with Spotify. Desktop Windows and MacOS have Djay Pro that does the same.

What I'd like to do is hack Spotify support into a player that's open source, cross-platform (on desktop/x86 at least), and does pitch shifting in the sample domain (e.g., WSOLA + resampling) instead of the frequency domain (e.g., phase vocoder FFT) because I can't stand the "phase shifted" echo sound that every single phase vocoder FFT implementation hasn't figured out how to solve (if possible at all). For me that would ideally be Rhythmbox, as I'm able to get that to compile and run on MacOS and Linux at least, and probably Windows with a little more work.

So can librespot support my weird use case, or is obtaining the raw bytes of the PCM still off-limits for out-of-process players?

[kingosticks]

@allquixotic if you just want to playback Spotify through a customisable gstreamer pipeline then have you tried Mopidy-Spotify?

[allquixotic]

Hey Nick -- I've used mopidy-spotify extensively in the past, though I'm concerned it might be broken right now based on the latest issue reported at https://github.com/mopidy/mopidy-spotify/issues/153 . Are you using librespot or the legacy libspotify? Also, it sounds like your next step is to encourage me to contribute some kind of support into mopidy for dynamically altering the parameters of the pitch, tempo and speed properties of the pitch element added to the pipeline... Kinda like I did with rbpitch... ;-D

Problem is, I am not a fan of Python. But I may end up having to dance with the devil if that's the shortest path to my goal.

[kingosticks]

Mopidy-Spotify will continue to use libspotify for playback for the time being. Personally I'm currently using both as Spotify Connect is the killer feature only available in librespot and it's probably the most often requested feature. I wish I had the time to look at integrating at least that part of librespot into Mopidy-Spotify.

I don't want to hijack this thread any more than I have but if you are interested in dancing then get in touch. But note that dynamically changing the gstreamer pipeline in Mopidy isn't currently exposed like I think you want, so it might be some work.