Nope that’s hw 1,0 but i’ve been aware of that and made the change.
Tried to delete that channels thing and add default to raspotify. No progress.
With
OPTIONS=–device hw:1,0
i have sound again but it bypass eq obviously…
Hi again,
Here is journactl return.
Some permission trouble ?
DietPi librespot[6260]: [2021-05-26T13:02:42Z ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_open' failed with error 'EPERM: Opera
tion not permitted'
mai 26 15:02:42 DietPi librespot[6260]: [2021-05-26T13:02:42Z ERROR librespot_playback::player] Could not start audio: Alsa error: PCM open failed
mai 26 15:02:42 DietPi librespot[6260]: [2021-05-26T13:02:42Z ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_open' failed with error 'EBUSY: Devic
e or resource busy'
mai 26 15:02:42 DietPi librespot[6260]: [2021-05-26T13:02:42Z ERROR librespot_playback::player] Could not start audio: Alsa error: PCM open failed
mai 26 15:02:42 DietPi librespot[6260]: [2021-05-26T13:02:42Z ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_open' failed with error 'EBUSY: Devic
e or resource busy'
mai 26 15:02:42 DietPi librespot[6260]: [2021-05-26T13:02:42Z ERROR librespot_playback::player] Could not start audio: Alsa error: PCM open failed
mai 26 15:02:42 DietPi librespot[6260]: thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', playback/src/audio_backend/alsa.rs:138:45
mai 26 15:02:42 DietPi librespot[6260]: stack backtrace:
mai 26 15:02:42 DietPi librespot[6260]: 0: 0x8c2278 - std::backtrace_rs::backtrace::libunwind::trace::h9c6af82ecb947420
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/../../backtrace/src/backtrace/libunwind.rs:96
mai 26 15:02:42 DietPi librespot[6260]: 1: 0x8c2278 - std::backtrace_rs::backtrace::trace_unsynchronized::h80561bf66e637b12
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/../../backtrace/src/backtrace/mod.rs:66
mai 26 15:02:42 DietPi librespot[6260]: 2: 0x8c2278 - std::sys_common::backtrace::_print_fmt::h8904fddc87bf6b5e
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:79
mai 26 15:02:42 DietPi librespot[6260]: 3: 0x8c2278 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc883ceb7a13219f2
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:58
mai 26 15:02:42 DietPi librespot[6260]: 4: 0x8ea290 - core::fmt::write::ha75209c8e86bef45
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/fmt/mod.rs:1080
mai 26 15:02:42 DietPi librespot[6260]: 5: 0x8bae18 - std::io::Write::write_fmt::h4cce8be81a41c537
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/io/mod.rs:1516
mai 26 15:02:42 DietPi librespot[6260]: 6: 0x8c51c0 - std::sys_common::backtrace::_print::hdc9e28891c09ab0b
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:61
mai 26 15:02:42 DietPi librespot[6260]: 7: 0x8c51c0 - std::sys_common::backtrace::print::h85895381379b4dc1
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:48
mai 26 15:02:42 DietPi librespot[6260]: 8: 0x8c51c0 - std::panicking::default_hook::{{closure}}::h6b4de484f2428118
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:208
mai 26 15:02:42 DietPi librespot[6260]: 9: 0x8c4dbc - std::panicking::default_hook::h3966366a200b03f1
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:227
mai 26 15:02:42 DietPi librespot[6260]: 10: 0x8c5910 - std::panicking::rust_panic_with_hook::h068b5368b0949ced
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:577
mai 26 15:02:42 DietPi librespot[6260]: 11: 0x8c54c4 - std::panicking::begin_panic_handler::{{closure}}::hde463ebfc6f96538
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:484
mai 26 15:02:42 DietPi librespot[6260]: 12: 0x8c27f8 - std::sys_common::backtrace::__rust_end_short_backtrace::hb945924c40726c97
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153
mai 26 15:02:42 DietPi librespot[6260]: 13: 0x8c547c - rust_begin_unwind
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
mai 26 15:02:42 DietPi librespot[6260]: 14: 0x8e7960 - core::panicking::panic_fmt::h27b19d6e6dedd33e
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
mai 26 15:02:42 DietPi librespot[6260]: 15: 0x8e78bc - core::panicking::panic::h2a6f9b05d102de10
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:50
mai 26 15:02:42 DietPi librespot[6260]: 16: 0x54e020 - <librespot_playback::audio_backend::alsa::AlsaSink as librespot_playback::audio_backend::Sink>::write::hfb124b87fed1cc15
mai 26 15:02:42 DietPi librespot[6260]: 17: 0x52b304 - <librespot_playback::player::PlayerInternal as futures::future::Future>::poll::he6e04a5bccf94e34
mai 26 15:02:42 DietPi librespot[6260]: 18: 0x48f300 - futures::task_impl::std::set::hab1c1811473e3998
mai 26 15:02:42 DietPi librespot[6260]: 19: 0x485838 - std::sys_common::backtrace::__rust_begin_short_backtrace::h8286c5a0fd04a387
mai 26 15:02:42 DietPi librespot[6260]: 20: 0x4a04f4 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h76e6c7604d7daced
mai 26 15:02:42 DietPi librespot[6260]: 21: 0x8cc940 - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h6b7ad05f87ff90ae
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/boxed.rs:1042
mai 26 15:02:42 DietPi librespot[6260]: 22: 0x8cc940 - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::he9130e675b8d97ee
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/boxed.rs:1042
mai 26 15:02:42 DietPi librespot[6260]: 23: 0x8cc940 - std::sys::unix::thread::Thread::new::thread_start::h7a3f6590d8e03e95
mai 26 15:02:42 DietPi librespot[6260]: at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys/unix/thread.rs:87
–device hw:1,0 bypasses the equalizer indeed, as this is the name of the final raw PCM. With equalizer enabled, audio should go this way:
Source => plug software conversion ("default") => equalizer ("eq") => plug software conversion => PCM ("hw:1,0")
When you use “hw:1,0”, it’s:
Source => PCM ("hw:1,0")
I see many “resource busy” logs, like multiple players try to concurrently access the audio device, while by default ALSA allows only one connection at a time, blocking the others. Probably “stopping” the audio stream and starting it again is somehow too much delayed, overlapping or so.
But also “‘snd_pcm_open’ failed with error ‘EPERM: Operation not permitted’”. The raspotify user is member of the “audio” group, right?
groups raspotify
else
usermod -aG audio raspotify
Yup Raspotify is in audio group .
Don’t really know where to look now.
Anychance with dmix ?
I tried that : https://linustechtips.com/topic/1137168-enable-usb-dac-on-raspotify/
But just like you said for putting hw1 into raspotify conf, it bypass eq if i undestand asound.conf.
I tried to adapt that procedure with plugequal part but with no success cause i’m not good with that 
.
The dmix plugin indeed allows multiple players to play audio concurrently, hence should solve the “device busy” error. I personally would have a look into why Raspotify alone does concurrent audio device accesses, as it is/should be a single application player, but let’s see if dmix does the magic when adding it after the final hardware PCM. The “dmix:1,0” is one of the pre-defined PCMs, which is a dmix stage with a hw slave one card 1 device 0.
cat << '_EOF_' > /etc/asound.conf
pcm.!default {
type plug
slave.pcm {
type equal
slave.pcm {
type plug
slave.pcm "dmix:1,0"
}
controls "/var/lib/dietpi/dietpi-config/.alsaequal.bin"
}
}
ctl.eq {
type equal
controls "/var/lib/dietpi/dietpi-config/.alsaequal.bin"
}
ctl.!default {
type hw
card 1
}
_EOF_
Too bad the magic didn’t happen.
Alsa error PCM open ALSA function 'snd_pcm_open' failed with error 'EPERM: Opera
tion not permitted'
Just to rule it our, please try:
chmod 0666 /var/lib/dietpi/dietpi-config/.alsaequal.bin
chmod 0775 /var/lib/dietpi/dietpi-config /var/lib/dietpi
Love you man.
It works now. Even with default justboom script ( so without dmix)
Just a strange thing : equalizer is on but appears off in justboom and i can’t acces eq menu. If i launch alsamixer -D eq, menu is here and changes affect sound just like it’s suppose to.
Auuu, you’re right, the equalizer status is not detected correctly. This should fix it: https://github.com/MichaIng/DietPi/pull/4448/files
Good that it works now. So I guess that either /var/lib/dietpi/dietpi-config or /var/lib/dietpi had permissions that didn’t allow users other than root and dietpi from reading the content. I think we set it that way a whole ago. Just to be sure:
chmod 0644 /var/lib/dietpi/dietpi-config/.alsaequal.bin
This does not break it, right? Just to rule out that Raspotify is trying to change something at the control/mixer device.
Huhu it does break it !
No sound with 644.
Back with 666, doesn’t really know if that is a good thing 
Very strange 
. When playing audio, only reading the equalizer control file should be sufficient and Raspotify shouldn’t know about the control device to change the equalizer.
I have to run some tests with other players, I think.
Does the following work with 0644 permissions?
sudo -u raspotify speaker-test
Hi,
Sorry for the very late reply.
No it does not work.
Forbiden operation.
Also had to do chmod 666 again after updating to 7.3.
Thanks, I guess we should to use 0664 and dietpi:audio for that file. That should be fine as all audio software users need to be member of that group anyway to be able to use the ALSA devices for playing sound.
Hi,
sorry, i’m back with the same problem, months later.
I use usb DAC, and raspotify. It works without eq.
It was working with alsa eq since we solved permission troubles.
After the last update i got this again :
ERROR librespot_ playback::player] Audio Sink Error Connection Refused: <AlsaSink> Device default May be Invalid, Busy, or Already in Use, ALSA function 'snd_pcm_open' failed wi th error 'EPERM: Operation not permitted'
avril 09 08:52:27 DietPi systemd[1]: raspotify.service: Main process exited, cod e=exited, status=1/FAILURE
avril 09 08:52:27 DietPi systemd[1]: raspotify.service: Failed with result 'exit -code'.
already try :
chmod 0666 /var/lib/dietpi/dietpi-config/.alsaequal.bin
chmod 0775 /var/lib/dietpi/dietpi-config /var/lib/dietpi
As the first line had to be done after every update.
It does not work anymore.
Any idea ?
Which SBC/hardware was it again? I hope it is not the broken onboard audio on RK3399 or possibly other Armbian kernel based systems since Linux 5.15: https://github.com/MichaIng/DietPi/issues/5337
Let’s check whether available audio devices and ALSA config still match:
aplay -l
cat /etc/asound.conf
Sry for the delay, been busy here.
I was writing a looong message with all errors but doing this i found out a solution.
So the problem is reported here :
https://github.com/dtcooper/raspotify/issues/475
I moved .alsaequal into /var/lib/raspotify as suggested
Then i had too chmod 666 to it and voilà !
Not sure exactly if this is a good solution nor how to fixe that for good.
Anyway it works now.
In /etc/asound.conf the /var/lib/dietpi/dietpi-config/.alsaequal.bin path is defined explicitly, so as long as Raspotify uses the default audio device, the previous path should have been correct. But if Raspotify uses a PCM directly instead of “default”, then yes, the respective user’s home dir is used by default for .alsaequal. Instead of 666, I’d just chown it:
sudo chmod 644 /var/lib/raspotify/.alsaequal
sudo chown raspotify /var/lib/raspotify/.alsaequal
So only Raspotify has write access. The question remains why it actually requires write access as long as it does not actually change equalizer settings .
Ah, read now: https://github.com/dtcooper/raspotify/issues/475#issuecomment-992776793
Nasty, we actually want to have the systemd unit started by systemd itself and hence to run it as static “raspotify” user which fixed permissions instead of using a dynamic user which may be this or that depending on how the service is starts… Probably we need to override the systemd unit then to have proper, and especially fixed permissions.
Hello guys, i have a simular issue that equalizer shows up but changes are not effecting the audio signal. I tried the steps in the post above, but without any success.
I run a mupibox (as far as i know use the mplayer)
More info: DietPi v8.20.1 on a RPi 3 Model B (armv7l)
My asound.conf:
pcm.!default {
type plug
slave.pcm {
type equal
slave.pcm {
type plug
slave.pcm {
type hw
card 0
device 0
}
}
controls "/var/lib/dietpi/dietpi-config/.alsaequal.bin"
}
}
ctl.eq {
type equal
controls "/var/lib/dietpi/dietpi-config/.alsaequal.bin"
}
ctl.!default {
type hw
card 0
}
Would be sooo cool to be able to change the eq. I search now for some hours on google and co without any success.
Thank you
Andreas
Does the player probably use the hardware PCM directly instead of the default ALSA device? I.e. does it show an effect when you pay a wav file via aplay?