Spotify Soloist uses PulseAudio because it targets broad Linux compatibility, offering automatic mixing, device switching, and easier handling of multiple audio applications. Volumio, on the other hand, is built around ALSA for direct, bit-perfect access to the DAC, which is preferred in audiophile systems.
In short: PulseAudio prioritizes convenience and compatibility, while ALSA prioritizes audio performance and exclusivity. That’s why integrating Soloist into Volumio requires an extra bridge between the two worlds. (Which doesn’t make it better, but needed)
Let me use your question as an excuse to set a few things straight and get something off my chest.
What frustrates me most with Spotify is that, again and again, both their technical choices and their product policy seem to be made with almost no benefit for the end user.
More restrictions, more proprietary layers, more fragile integrations — but rarely better interoperability, flexibility or user control.
Maybe this is Scandinavian minimalism taken a little too far: fewer APIs, fewer options, fewer integrations… apparently even user freedom had to be streamlined.
At some point it becomes difficult to see these decisions as being driven by the actual user experience.
And to wrap this up, to paraphrase a great man around here:
One note on how reports are handled here, because it directly affects whether yours can be acted on.
This is a plugin under active development. Reports that arrive in fragments - a symptom in one post, a hardware detail in an edit, a partial log later - cannot be investigated. Each fragment restarts the analysis, and none of them on its own contains enough to reproduce anything. This has been clearly stated in the opening post.
You choose not to provide requested details I choose not to invest my time in investigating.
In short, one post containing:
Exact Volumio version (for example 4.123, not “latest”)
DAC or output device in use, and how it is connected
Exact steps to reproduce
What actually happens
What you expected to happen
A log link from http://<volumio_IP>/dev
On logs: /tmp and /var/log are held in RAM. A reboot destroys them. The log must be collected after reproducing the problem and before any power cycle.
Pasted extracts chosen by the reporter are not a substitute for the full log link. A section that looks unremarkable to you is frequently where the failure is actually recorded, and the surrounding context is what makes it readable.
We are glad to have testers and every complete report is read and worked on. Where the requested details are not supplied, the problem cannot be reproduced, and it will not be progressed. That is not a judgement of anyone - it is the limit of what can be done without the information.
Sorry if this is a schoolboy question. I’m following this thread and the new plugin with great interest. With each new release, do we need to download and install it again, or does the plugin automatically update to the latest version?
For now, yes: each new alpha means uninstalling the plugin and installing the latest from git. There is no auto-update while it lives outside the Plugin Store.
Once it lands in the store as a beta, updates will come through the normal plugin update mechanism and none of this will be needed.
One thing worth knowing in the meantime: the update button inside the plugin settings only refreshes the Soloist binary from Spotify’s CDN. It does not update the plugin itself.
From hidden dev hot-desk: A note on how Soloist gets its audio out:
As it was already explained - Soloist has no ALSA backend. It wants PipeWire, or PulseAudio as a fallback. Volumio has neither, by design.
The first attempt bridged that with apulse. It got us playing quickly, and then cost us most of a week. It implements an old snapshot of the PulseAudio client API, aimed at desktop apps that own the sound card outright. Volumio shares that device with other sources, with DSP and with metering. Every fix worked and exposed the next one: when to release the device, what to report about buffering, how to behave when something else wants to play. We were not fixing bugs, we were arguing with assumptions baked into a library written for a different machine.
So it went.
Soloist never links PulseAudio. It loads the library by name at runtime and asks for 47 functions. That list is the entire requirement, and it is short. The plugin now carries its own small library that answers exactly those and does nothing else. I call it the ALSA shim, and it ships from 0.6.3 onward.
What that changes:
Releasing the device, holding it across a pause, behaving under metering: designed in, not patched on.
Five source files. Links ALSA and libc only, where apulse dragged in GLib and PCRE.
No fork to maintain, no pinned revision, no waiting on a project that has been quiet for over a year.
When something breaks, it is our code, in one place, written for this chain.
It is not a PulseAudio replacement and not an apulse alternative. It answers what one binary asks for. Nothing extra is installed on your device.
I compared the Volumio Rivo+ Spotify Soloist Connect with the Bluesound Node 2024.
For me, the Node has better sound over the Spotify Connect.
Rivo+ I2S → Denafrips Pontus 15TH
Node USB → Denafrips Pontus 15TH
Could this be true?
The Node can sound different. That comparison does not show that its Spotify Connect is inherently better than Soloist on the Rivo+.
Spotify Soloist Connect on Volumio does not do bit-perfect. Soloist is a closed binary: it decodes every quality to FLOAT32 and speaks Pulse, not ALSA. The plugin’s job is to get that into pcm.volumio so Volumio’s volume, DSP and the rest of the chain still apply. Softvolume then converts to S24_3LE for the DAC. That conversion is real. We do not have the original file bytes, and we cannot invent them.
Volumio’s bit-perfect idea is for sources that are already integer PCM (a FLAC in MPD, for example). Soloist is not that kind of source. Staying on pcm.volumio is the point of the plugin. Leaving it to “sound closer to the Node” would drop volume and DSP. That is a different product.
Your A/B is also two different inputs on the Pontus: Rivo+ I2S versus Node USB. Different clock, different electrical path, same DAC badge. That alone can change what you hear, even if the bits were identical. BluOS is another client and another pipeline; I do not know whether it is bit-perfect either. I do know ours is not.
If you want the comparison to mean something: same Spotify quality on both, levels matched, trim at 0, DSP off, and ideally the same Pontus input. Then a remaining difference can be the convert in the Volumio chain. It can also still be I2S versus USB.
So: yes, there is a technical reason the Rivo+ path is not a straight wire. No, that listen does not prove the Node’s Connect implementation is better. I am not promising a bit-perfect Soloist. The file never arrives here as those bits.
The earlier reply still stands: Soloist decodes to FLOAT32, we stay on pcm.volumio, and this is not bit-perfect. The file bits never arrive here.
What changed is the convert. The shim now packs that float to S24_3LE (or S24_LE / S16_LE if the chain will not take packed 24) before writei, and it asks for the exact sample rate with resample off. Softvolume can still apply gain. DSP, if enabled, still applies.
That is one conversion we own, not two. It does not make the Rivo+ I2S path the same as the Node on USB, and I am not claiming it will. If you try 0.6.4 on the same Pontus setup, use trim 0, DSP off, and matched levels. A remaining difference can still be I2S versus USB.
0.6.4 still stays on pcm.volumio. The one playback change that can affect tempo is that we now ask for the track’s exact sample rate and turn ALSA resample off unless that open fails. The integer convert does not change speed.
Turn Verbose logging on, play until it rushes, I need to see the pcm open line (it has rate=, fmt=, resample=). Also whether FusionDSP was on. That will show whether the box opened at 44.1 while the DAC or DSP was at another rate.
Please start from the top of this thread all way down to the bottom. It boils down to:
0.6.4 asks for the track rate with ALSA resample off. FusionDSP is in the chain. You opened at 44.1 (44100,S32_LE) on a lossless track, and Camilla then reports the FIFO at ~48 kHz every second. That is a rate mismatch, not a bad file. It will sound fast or unstable.
Without DSP:
This dump has FusionDSP out of asound.conf. The Camilla 48 kHz lines are from the earlier PEQ session; they stop before the restart.
The lossless track is 44.1. 0.6.4 opens that rate with ALSA resample off. Integro still has a plug in front of the AML card, so the open can succeed at 44.1 while the card runs 48 kHz. That plays fast. Same hole with or without DSP.
I cannot reproduce it here on a 44.1 DAC with DSP off. Your box is the case we were missing.
We will put defensive resample back on so the plug converts when the slave is not 44.1. I will say when that build is up.
0.6.4 asked for the track rate with ALSA resample off. On Integro that played 44.1 lossless too fast, with or without FusionDSP. 0.6.5 puts resample back on. The float-to-S24 convert is unchanged.
Verbose log line to look for: pcm open … resample=1.
Please try lossless again on Integro and on the Rivo+.
