Spotify has recently introduced their own solution for headless setups:
It think it has some caveats (esp. the fact that builds expire after 90 days), but it might be a path towards Spotify Lossless support on RoPieee. Any thoughts on Spotify Soloist from other RoPieee users already?
I think you can see it as a possible alternative for Librespot and it can be an interesting option for RoPieee, but I don’t think it can facilitate all use case that Libresport currently serves.
The software can’t be distributed (neither can Roon), and an API key is needed before generating the build. As you say, this process would need repeating before the 90 days is up.
What a palaver.
Soloist is quite brilliant: it has all the preference settings of the Desktop version, a full blown control cli and a websocket API to boot – basically all ingredients a commercial Connect implementation has at its disposal. And it runs just fine in a virtual Linux machine on my Mac. 
I have implemented all three this afternoon: load at boot and keep-alive via systemd, ctl commands mapped to my Flic buttons and the API connected to Baton (my control app for my KEF LS60): realtime track control and now playing & queue metadata updates directly into the app.
It is a developer trait right now – and I am sure they’re not waiting for a litter of devices in the wild without a form of control. So yes – a minor annoyance for home use and a major hurdle for distribution. Exactly as intended, I’m afraid…
Theoretically this could be great for RoPieee: the required low level stuff is something I can take care of. And the fact that this is straight from Spotify is also great.
The biggest issue I see right now is the API key. Maybe I should try to contact them and see if it would be OK to have a ‘RoPieee API key’.
Ah well. Maybe this is me dreaming.
So I looked into it a bit…
I think the licence makes it possible for RoPieee to download Soloist upon installation (same as with Roon: the Roon license forbids RoPieee to ship RoonBridge, but downloading is allowed).
And just deal with your personal API key: creating it is relatively easy, and the only thing that should be able to do is provide it in RoPieee’s webpage.
And as RoPieee is updated at least once a month, the 90-days period shouldn’t be a problem.
Hmmm…
ok… in line with @RBM’s findings: this is trivial to setup.
My fingers are itching…
Soloist does make it possible to support Spotify Lossless. A plugin has been created for Volumio.
As always, there’s a caveat: I have run a round of measurements and found Soloist to add volume normalization at all times. It does respond however to
audio.normalize_v2=false
in user prefs.
Changing the settings requires to stop the daemon first, as settings will be (over)written at close. Stop soloist / adjust settings / restart soloist does the trick.
Thanks René.
What I’m going to do is implement this next to current Spotify (librespot) component. This gives us the time to test it out and see if could be a full replacement. furthermore time will tell how Spotify will deal with this and will keep on developing it further.
For RoPieee there’s one thing that will take me some time: Pipewire support. I already started with that (independantely of Soloist), but that’s far from done.
Cool. I have been running Soloist inside a Debian ARM VM on my Mac mini for a few days now – works flawlessly. Main stumbling block with pipewire was to set the sampling rates explicitly to avoid pipewire resampling everything to 48kHz:
context.properties = {
default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 ]
}
With context set, pipewire follows rate changes neatly. That – and the normalization thing.
All set now – next up is the bedroom Pi. (Hey – I have a few days off and it’s raining outside… ;-)).
One more – then I’ll stop.
I finished the Pi with soloist & pipewire – practically the same as the VM. I run two soloist instances to two different USB devices in parallel, so each one is a connect endpoint of its own (one normalized, one not). Switching between the two is fast and fine.
Now it’s time to stop toying and start playing, I guess.
Good luck Harry – looking forward to the betas!
for apps like soloist that cache full media files to disk … might be nice to have an option on RoPieee to attach extra storage (usb thumb drive?) and use this for apps with a large media cache (soloist, someday/maybe caldera headless, others?) … i don’t know if this aligns with RoPieee’s appliance use model, and it would probably only work on certain pi models (usb ports, bandwidth), but i thought it might be worth considering
Cannot happen
i think these are “conditional downloads” as described in the link you shared … as far as i can tell, with soloist this is enabled by default (and in fact by default there is no limit to the amount of disk space available for caching) … so it’s just a matter of where to put it and how much space to allocate
but yeah, good idea to study the developer terms closely
Looking a bit further, I think the max cache is 100mb. Volatile cache.
My limited understanding thus far is that it’ll cache the song currently playing and maybe 2 to 3 tracks ahead to retain gapless playback.
I don’t think this will work with RoPieee. From what I’m reading, you can only link a user to the page for the user to do the hard work of downloading and installing.
I think it’s possible to handle all this in memory via Tmpfs if mandatory, but @spockfish is for sure better suited to shine a light on this.