Hardware volume break is something I did not understand where it comes from. So I’ve not been able to fix it.
The option just doesn’t appear in the list anymore. It really is the best way, so it needs to be returned.
There is something wrong with the default configuration for the spotify plugin.
I always (after installing) have to edit /etc/spopd.conf and change hw to plughw, for example:
[spop]
spotify_username = ---------------------
spotify_password = --------------------
high_bitrate = true
audio_output = sox
pretty_json = true
search_results = 50
cache_path =/run/shm
[sox]
output_type = alsa
output_name = hw:5In the last line change hw to plughw, so in my example:
output_name = plughw:5After this change, stop and restart the spotify plugin or reboot.
If I don’t make this manual configuration change I either get no sound at all, or the music plays at 2x (chipmunk speed) for a few seconds then goes silent…
I don’t have any problems with local medial playback (mpd) or spotify connect 2, or qobuz or tidal. Only the spotify plugin.
Those having problems with corrupt or silent playback in spotify check the output_name setting in the conf file and if the output device is hw try changing it to plughw.
Note that this change will get reverted if you uninstall and reinstall the spotify plugin, or make certain changes to the system playback settings.
Thanks for this hint! It means that your USB DAC cannot handle the bitdepth that spop wants to play to, therefore it results in bad sound. I will apply your mod to the official plugin. Thanks again
Do you mean sample rate not bit depth ? The audio playback before making this change is roughly 2x the speed it should be and then stops, so I would think this is a sample rate issue not bit depth.
What bit depth and sample rate is spop trying to use by default ? My USB DAC supports all bit depths (16, 24, 32 float) and sample rates (44.1, 48, 88.2, 96, 174.6 and 192Khz) that it could possibly use, so I don’t understand why hw doesn’t work properly and plughw (resampling in ALSA) does work.
I think it’s more likely a bug in how spop opens the ALSA device than a problem with the DAC as the DAC can handle natively any valid sample rate spop could throw at it.
Is there more debugging that we can do to try to pin this down more precisely ? Shall I post the playback info from /proc/asound with spop playing with both hw and plughw ? Using plughw may just be working around a bug in spop and not the best fix.
I wonder if anyone else in this thread having problems has tried the plughw workaround yet ?
Here is the output from /proc/asound/card5/pcm0p/sub0/* with spopd.conf set to hw:5 and bad playback:
[code]access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 4
rate: 44100 (44100/1)
period_size: 1024
buffer_size: 8192
card: 5
device: 0
subdevice: 0
stream: PLAYBACK
id: USB Audio
name: USB Audio
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
state: RUNNING
owner_pid : 1104
trigger_time: 243.457646197
tstamp : 0.000000000
delay : 7796
avail : 457
avail_max : 7168
hw_ptr : 80330
appl_ptr : 88065
tstamp_mode: NONE
period_step: 1
avail_min: 1024
start_threshold: 1
stop_threshold: 8192
silence_threshold: 0
silence_size: 0
boundary: 1073741824[/code]
As you can see, playback is 44.1Khz at 16 bit - so the issue is not a sample or bit depth that the soundcard cannot handle. Here is the output when spopd.conf is changed to use plughw:5 and playback is good:
[code]access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 4
rate: 44100 (44100/1)
period_size: 2048
buffer_size: 16384
card: 5
device: 0
subdevice: 0
stream: PLAYBACK
id: USB Audio
name: USB Audio
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
state: RUNNING
owner_pid : 2658
trigger_time: 348.612783270
tstamp : 0.000000000
delay : 16214
avail : 215
avail_max : 4101
hw_ptr : 92375
appl_ptr : 108544
tstamp_mode: NONE
period_step: 1
avail_min: 2048
start_threshold: 1
stop_threshold: 16384
silence_threshold: 0
silence_size: 0
boundary: 1073741824[/code]
The only thing of significance I can see is period_size and buffer_size are both doubled compared to what they were with hw:5. However the sample rate and bit depth are still the same.
I also captured the output of /proc/asound/card5/stream0 during playback, however it is identical in both the bad and good configurations:
[code]BEHRINGER UMC204HD 192k at usb-0000:01:00.0-1.4, high speed : USB Audio
Playback:
Status: Running
Interface = 1
Altset = 2
Packet Size = 72
Momentary freq = 44099 Hz (0x5.8328)
Feedback Format = 16.16
Interface 1
Altset 1
Format: S32_LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Interface 1
Altset 2
Format: S16_LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Capture:
Status: Stop
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us[/code]
Any ideas what could be causing this ? It still seems like a bug in spopd to me as the sound card supports the rate wanted by spopd, and all other processes like shairport, mpd and so on have no problems. It almost seems like there is a timing issue with spopd and that somehow going through plughw works around it.
Since spopd seems to output at 44.1Khz 16 bit and every sound card should support that, even if plughw is used the audio should not be resampled because as far as I know plughw will only use software resampling if the sample rate is one not supported by the card but pass through streams that are at supported sample rates…
By the way a google search turned up these:
volumio-spotify-usb-dac-too-fast-playback-t2462.html
runeaudio.com/forum/spotify … t3609.html
One is the same problem reported on Volumio 4 years ago, the other on rune, so it is not volumio specific.