I’ve been attempting to stream to Volumio via the Jamcast Spotify plugin. This setup currently appears to be the best solution to getting Spotify on Volumio without sacrificing sound quality (ie. Mopidy).
While UPnP device discovery, searching, and push requests are working perfectly, MPD playback of the audio/L16 stream is failing. Sometimes it will refuse playback altogether, other times will result in whitenoise or heavily distorted squeals, but nothing resembling the music playing.
Is there any reason why MPD fails to render these streams, or anything that can be done in future releases to get it working?
Hi michelangelo! As I understand, Airfoil just sends the PC Audio output to the device, yeah? This isn’t really an option for me as I don’t have an Audio device enabled on my server nor I don’t really want have the full spotify software running on that system.
The Jamcast solution, using the spotify plugin, is ideal since it acts as a full DLNA server for spotify without requiring the spotify software or additional software.
Anyway, if we can’t get audio/L16 to stream, I’ll definitely look at accommodating Airfoil into my setup.
Ok, gotcha. Could you please explain what L16 means? We can however investigate and understand whats going wrong via mpd log, so you can enable mpd logging and paste it here. If you don’t know how to do it, let me know and I’ll guide you trough it
Ok, my upmpdcli logs are here: pastebin.com/pqF5xaAr I set verbosity to the highest, so there’s a lot of junk in there, but you can see a few instances where I’ve attempted to push spotify tracks to the device.
As a side note, isn’t it about time someone wrote a proper mpd plugin to handle spotify playback? Mopidy is a great piece of software and it’s really cool what they’re doing with it, but it just lacks the audio quality and stability options of mpd. I remember a few offshoots of the despotify project looking promising, but they seem to have been lost to the wind. Oh well
Oh yes sir. I suffer a lot for this lack of MPD. I worked last summer to have spotify integrated, then it all changed and it stopped working, suddenly. Maybe we can ask to mantainers if someone is willing to do that, and offer our help… And I agree on the quality: that is why I’m still with MPD, mopidy just doesn’t sound as good.
As far as I know, L16 is a raw PCM stream (no encapsulation, no headers). The problem here is that upmpdcli has no way to tell MPD what the stream characteristics are (bit depth, sample rate etc.). MPD normally retrieves these from the file header, which is absent, and there is nothing in the MPD client protocol to send the info while adding an URL (upmpdcli does have the information, it’s communicated by the UPnP control point which gets it from the Media Server).
I think that I’ll just remove these formats from the supported ones, because I can’t find a way to make it work (this is a call for help by the way, if anyone gets an idea).
I’m afraid I can’t help resolve the issue, but removing the format as supported could be a quick and dirty fix for this specific problem. As I understand, the Jamcast software trancodes streams for devices which don’t list support for the original format. It would also, of course, cause a drop in sound quality due to transcoding one lossy format to another, but that’s probably a hit I’m willing to take just for spotify compatibility.
If Jamcast is able to “transcode” to Wav (this is no transcoding, just adding a header), there should be no loss in quality (same bits exactly as L16 except for the added header).
I’m not sure of what upmpdcli version is currently in Volumio. In the last version (0.7.1), you can tune the list of advertised formats just by editing a text file: /usr/share/upmpdcli/protocolinfo.txt
You just need to delete the lines for audio/L16 and restart upmpdcli.
Actually, I just checked, and the audio/Lxx formats are already commented out in the 0.7.1 protocolinfo, so updating the package would be enough (no file editing needed).
If the file does not exist, the upmpdcli version is not the latest, and you would have to update the package for changing the list.
Success! Mostly… I had to disable WAV also as mpd was having the exact same issue with it. I’m assuming there may be an issue with the headers being attached by Jamcast. Not to worry though, 320kbps mp3 seems to be adequate for Spotify.
michelangelo, if the version of upmpdcli isn’t already >= 0.7.1, could we get the packages upgraded and the relevant config changes made for the next release? When I find the time, I’ll write up a short tutorial for getting Jamcast+Spotify up and running with volumio, if there’s any interest.
About the wav issue: I can’t be totally sure without testing for myself, but this is very likely to be related to a bunch of problems which we are having with high data rate formats and the upmpdcli/mpd couple.
The thing which is special when you use upmpdcli to control mpd is that all data retrieval goes through curl (HTTP), instead of normal file access system calls, for the more common situation where mpd accesses the audio data inside its music directory.
The thing which is special about curl is that read requests sometimes return less data than was requested.
This tends to happen more with high data rates and mostly causes problems with less commonly streamed formats (the mp3 decoder was probably fixed for short reads ages ago), and it has awaken a whole nest of creepy-crawlies.
Specifically, problems were seen with:
wav files: you need to use the sndfile plugin (not audiofile which you should get completely rid of afaik), with a patch which is in the recent git MPD code, or can be applied to older versions. See this issue: bugs.musicpd.org/view.php?id=3968
Finally, about L16 again, there is a fundamental issue with using this with upmpdcli/mpd: we have no way to tell mpd about the sound format (sample rate, size, channel count), and mpd can’t guess because there is no descriptive header. There is no simple solution to this issue, this would need relatively significant modifications to mpd.
If anybody needs more details, I’ll check this thread, or you can reach me at jf at dockes . org.
This is an old thread, but it ends on a wrong conclusion, so here comes the truth:
The way the Media Renderers (e.g. upmpdcli/mpd) obtain data rate and channel count information for L16 streams is through HTTP headers returned when the renderer fetches the stream (I didn’t know this at the time of the original thread).
Older MPD versions did not know how to use this information. This is fixed in very recent MPD versions (0.20, not released yet).
I have 0.19 version of MPD patched with the 0.20 L16 support code (a simple change). Contact me if you have a need for this: firstname.lastname@example.org.