-
Notifications
You must be signed in to change notification settings - Fork 217
Troubleshooting
I just updated Raspotify and now none of my settings from
/etc/default/raspotifywork anymore?
Version 0.31.4 introduces breaking changes to the Raspotify Package. Please see the wiki for details.
I've installed Raspotify on a Raspberry Pi v1/Raspberry Pi Zero v1.x and it just keeps crashing?
Support for ARMv6 (Pi v1 and Pi Zero v1.x) has been dropped, as mentioned in the README.
I'm trying to update or install and apt tells me that I have unmet dependencies?
As per the README Raspotify only supports Debian Stable and other Debian Stable based/compatible OS's. You're more than likely running an out of date OS version.
My volume on Spotify is 100% and it's still too quiet?
Have you tried turning the volume up using the command alsamixer?
My Raspberry Pi does not use my sound card/device!
Well, 1st let's find your card/device (DAC) with aplay.
aplay -l should output something that looks like this:
**** List of PLAYBACK Hardware Devices ****
card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: DAC [JDS Labs Element DAC], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: DAC [JDS Labs Element DAC], device 1: USB Audio [USB Audio #1]
Subdevices: 1/1
Subdevice #0: subdevice #0
Now edit /etc/asound.conf. (It may or may not already exist.)
Add:
defaults.ctl.card <your DAC's card #>
defaults.pcm.card <your DAC's card #>
In the example above the DAC's card # is 2 so:
defaults.ctl.card 2
defaults.pcm.card 2
Now you can test it out with:
speaker-test -c2 -l1
If you hear noise you're good to go. Your DAC is configured as the default sound device.
I'm an audiophile and I want bit-perfect output?
Well, sorry... Spotify doesn't stream lossless audio currently.
To get as close as possible we're going to need to know what format(s) your DAC supports.
Wait, isn't the audio 16 bit 44.1 khz?
Well, it started out that way but lossy audio doesn't have a bit depth.
The decoder outputs 32 bit float 44.1 khz PCM and all digital processing in librespot is done in 64 bit float to be as lossless as possible.
That PCM has to be re-quantized back into an integer format for playback on most DACs.
The higher the bit depth the lower the quantization noise.
So we want librespot to output the highest bit-depth your DAC supports to get the highest quality sound possible.
To find out our example DAC's supported formats we're going to take the card # from above and use aplay again:
aplay -Dhw:2 --dump-hw-params /usr/share/sounds/alsa/Front_Right.wav
That should output something that looks kinda like this:
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S24_3LE S24_LE S32_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [32 64]
CHANNELS: 2
RATE: [8000 192000]
PERIOD_TIME: (166 8192000]
PERIOD_SIZE: [32 65536]
PERIOD_BYTES: [256 524288]
PERIODS: [2 4096]
BUFFER_TIME: (333 16384000]
BUFFER_SIZE: [64 131072]
BUFFER_BYTES: [256 524288]
TICK_TIME: ALL
--------------------
What we care about is FORMAT and RATE.
If the device supports a sampling rate (RATE) of 44100 we want to use that to avoid resampling. If not it will more than likely support 48000.
The example card does support 44100. ([8000 192000] is a range)
So in our /etc/asound.conf we want to add:
defaults.pcm.dmix.rate 44100
defaults.pcm.dmix.format S32_LE
All together our example /etc/asound.conf looks like this:
defaults.ctl.card 2
defaults.pcm.card 2
defaults.pcm.dmix.rate 44100
defaults.pcm.dmix.format S32_LE
librespot doesn't care about the endianness (the LE or BE at the end) it will take care of that for us.
To set the format to S32_LE change:
# Output format {F64|F32|S32|S24|S24_3|S16}. Defaults to S16.
#LIBRESPOT_FORMAT="S16"
To:
# Output format {F64|F32|S32|S24|S24_3|S16}. Defaults to S16.
LIBRESPOT_FORMAT="S32"
If you want to get really crazy you can disable volume normalization and volume control and set the initial volume to 100 to approximate bit-perfect as much as possible by uncommenting:
# Initial volume in % from 0 - 100.
# Defaults to 50 For the alsa mixer: the current volume.
#LIBRESPOT_INITIAL_VOLUME="50"
# Volume control scale type {cubic|fixed|linear|log}.
# Defaults to log.
#LIBRESPOT_VOLUME_CTRL="log"
And changing it to:
# Initial volume in % from 0 - 100.
# Defaults to 50 For the alsa mixer: the current volume.
LIBRESPOT_INITIAL_VOLUME="100"
# Volume control scale type {cubic|fixed|linear|log}.
# Defaults to log.
LIBRESPOT_VOLUME_CTRL="fixed"
How do I use/enable hardware volume control in
librespot?
The short answer is, you don't if you care about fidelity.
Unless you need some kind of advanced ALSA feature that requires you to use hardware volume control don't use it.
Software volume control in librespot in done with 64 bit floating point precision and is objectively better than any and all forms of hardware volume control.
I'm using the pipe backend with
snapcast/ afifoand theraspotifysystemd service keeps crashing!
The intention of the raspotify service is to output directly to a sound device not to pipe to a file or fifo. As such the provided service file uses best practices to limit the access that the raspotify service has to various system directories as much as possible which makes it very difficult to use librespot's pipe backend with the raspotify service. Issues related to piping to a file or fifo will be closed as invalid as they are out of scope of the intentions of Raspotify.
In the case of snapcast it's probably easier to disable the Raspotify service and just use the provided librespot binary directly from snapcast. In that case the burden of support shifts to snapcast. All issues related to snapcast and the librespot binary shipped with Raspotify will also be closed as invalid.
My onevent script doesn't work, what gives?
The provided raspotify service file uses best practices to limit the access that the raspotify service has to various system directories as much as possible. Much like the pipe backend use case that means that onevent scripts are not very useful as they are extremely limited in what they can actually do (basically nothing).
If you wish to use onevent scripts with librespot you will need to "roll your own" service file, at which point you will no longer be using Raspotify. All issues related to modified or custom service files will be closed as invalid as they are out of scope of the intentions of Raspotify.
I put my Spotify username and password in
/etc/raspotify/confand now I get a bunch of nag emails from Spotify?
Unless you have disable zeroconf (mDNS) discovery, librespot does not need your Spotify credentials, zeroconf with take care of authentication.
However if you have disabled discovery for whatever reason and you provided your credentials you will also want to enable credential caching so that librespot will cache the auth token and not have to login every time you connect. Unless you like nag emails ofc?
To enable credential caching change this in /etc/raspotify/conf:
# Disable caching of credentials.
# Caching of credentials is not necessary so long as
# LIBRESPOT_DISABLE_DISCOVERY is not set.
LIBRESPOT_DISABLE_CREDENTIAL_CACHE=
To this:
# Disable caching of credentials.
# Caching of credentials is not necessary so long as
# LIBRESPOT_DISABLE_DISCOVERY is not set.
# LIBRESPOT_DISABLE_CREDENTIAL_CACHE=
File an issue, and if we get it sorted, I'll add to this list.