Implement IPC for 3rd party applications. about librespot HOT 15 CLOSED

Comment by NeoLegends
Thursday Mar 10, 2016 at 09:09 GMT

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

from librespot.

Comment by psych0d0g
Monday Mar 14, 2016 at 15:22 GMT

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

from librespot.

Comment by sashahilton00
Monday Mar 14, 2016 at 15:57 GMT

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

from librespot.

Comment by NeoLegends
Monday Mar 14, 2016 at 16:12 GMT

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.

from librespot.

Comment by NeoLegends
Monday Mar 14, 2016 at 23:26 GMT

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

from librespot.

Comment by sashahilton00
Tuesday Mar 15, 2016 at 20:03 GMT

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

from librespot.

Comment by NeoLegends
Wednesday Mar 16, 2016 at 06:41 GMT

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.

from librespot.

Comment by NeoLegends
Sunday Apr 17, 2016 at 13:05 GMT

Are there any updates on this?

from librespot.

Comment by plietar
Monday Apr 18, 2016 at 16:08 GMT

@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.

from librespot.

Comment by sashahilton00
Wednesday Feb 01, 2017 at 01:57 GMT

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.

from librespot.

Comment by allquixotic
Thursday Jul 20, 2017 at 02:00 GMT

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?

from librespot.

Comment by kingosticks
Thursday Jul 20, 2017 at 15:36 GMT

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

from librespot.

Comment by allquixotic
Thursday Jul 20, 2017 at 15:41 GMT

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 mopidy/mopidy-spotify#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.

from librespot.

Comment by kingosticks
Thursday Jul 20, 2017 at 15:57 GMT

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.

from librespot.

As this is related to metadata I'm going to close it. Please see #7.

from librespot.