[GH-ISSUE #333] No audio - problem #217

Closed
opened 2026-02-27 19:29:28 +03:00 by kerem · 18 comments
Owner

Originally created by @Madvih on GitHub (Apr 23, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/333

Having this issue, when trying to play this error occurs:

  Process: 9366 ExecStartPre=/bin/chown raspotify:raspotify /var/cache/raspotify (code=exited, status=0/SUCCESS)
  Process: 9363 ExecStartPre=/bin/mkdir -m 0755 -p /var/cache/raspotify (code=exited, status=0/SUCCESS)
 Main PID: 9369 (librespot)
   CGroup: /system.slice/raspotify.service
           `-9369 /usr/bin/librespot --name raspotify (madosmc) --backend alsa --bitrate 96 --disable-audio-cache --enable-volume-normalisation --linear-volume --initial-volume=100

Apr 24 00:57:23 madosmc librespot[9369]: INFO:librespot_playback::audio_backend::alsa: Using alsa sink
Apr 24 00:57:23 madosmc librespot[9369]: INFO:librespot_core::session: Country: "CZ"
Apr 24 00:57:24 madosmc librespot[9369]: INFO:librespot_playback::player: Loading track "Dreaming Deeper" with Spotify URI "spotify:track:4KPRqt53xnT2Hs2rDGKiRu"
Apr 24 00:57:25 madosmc librespot[9369]: INFO:librespot_playback::player: Track "Dreaming Deeper" loaded
Apr 24 00:57:25 madosmc librespot[9369]: ERROR:librespot_playback::audio_backend::alsa: Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'
Apr 24 00:57:25 madosmc librespot[9369]: ERROR:librespot_playback::player: Could not start audio: Alsa error: PCM open failed
Apr 24 00:57:25 madosmc librespot[9369]: ERROR:librespot_playback::audio_backend::alsa: Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'
Apr 24 00:57:25 madosmc librespot[9369]: ERROR:librespot_playback::player: Could not start audio: Alsa error: PCM open failed
Apr 24 00:57:26 madosmc librespot[9369]: ERROR:librespot_playback::audio_backend::alsa: Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'
Apr 24 00:57:26 madosmc librespot[9369]: ERROR:librespot_playback::player: Could not start audio: Alsa error: PCM open failed

My audio is on SPDIF, I tried change of bitrate, reinstall, changing --device hw:0,1(what should be my SPDIF output)

But nothing helps.

Please help, if you know how.

Thank you

Originally created by @Madvih on GitHub (Apr 23, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/333 Having this issue, when trying to play this error occurs: ``` Process: 9366 ExecStartPre=/bin/chown raspotify:raspotify /var/cache/raspotify (code=exited, status=0/SUCCESS) Process: 9363 ExecStartPre=/bin/mkdir -m 0755 -p /var/cache/raspotify (code=exited, status=0/SUCCESS) Main PID: 9369 (librespot) CGroup: /system.slice/raspotify.service `-9369 /usr/bin/librespot --name raspotify (madosmc) --backend alsa --bitrate 96 --disable-audio-cache --enable-volume-normalisation --linear-volume --initial-volume=100 Apr 24 00:57:23 madosmc librespot[9369]: INFO:librespot_playback::audio_backend::alsa: Using alsa sink Apr 24 00:57:23 madosmc librespot[9369]: INFO:librespot_core::session: Country: "CZ" Apr 24 00:57:24 madosmc librespot[9369]: INFO:librespot_playback::player: Loading track "Dreaming Deeper" with Spotify URI "spotify:track:4KPRqt53xnT2Hs2rDGKiRu" Apr 24 00:57:25 madosmc librespot[9369]: INFO:librespot_playback::player: Track "Dreaming Deeper" loaded Apr 24 00:57:25 madosmc librespot[9369]: ERROR:librespot_playback::audio_backend::alsa: Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument' Apr 24 00:57:25 madosmc librespot[9369]: ERROR:librespot_playback::player: Could not start audio: Alsa error: PCM open failed Apr 24 00:57:25 madosmc librespot[9369]: ERROR:librespot_playback::audio_backend::alsa: Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument' Apr 24 00:57:25 madosmc librespot[9369]: ERROR:librespot_playback::player: Could not start audio: Alsa error: PCM open failed Apr 24 00:57:26 madosmc librespot[9369]: ERROR:librespot_playback::audio_backend::alsa: Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument' Apr 24 00:57:26 madosmc librespot[9369]: ERROR:librespot_playback::player: Could not start audio: Alsa error: PCM open failed ``` My audio is on SPDIF, I tried change of bitrate, reinstall, changing --device hw:0,1(what should be my SPDIF output) But nothing helps. Please help, if you know how. Thank you
kerem 2026-02-27 19:29:28 +03:00
  • closed this issue
  • added the
    audio
    label
Author
Owner

@ashthespy commented on GitHub (Apr 24, 2019):

Curious to know what your output device is - could you share details? Could you dump the hw_params when the device is playing something from some other source?
You might need to hunt for your actual card, but try along these lines:

cat /proc/asound/card0/pcm0p/info
cat /proc/asound/card0/pcm0p/sub0/info
cat /proc/asound/card0/pcm0p/sub0/hw_params

My guess would be that it doesn't support the predefined buffer size utilised in the current alsa implementation. Should probably add in a check against snd_pcm_hw_params_get_buffer_size_max to avoid this.

<!-- gh-comment-id:486148173 --> @ashthespy commented on GitHub (Apr 24, 2019): Curious to know what your output device is - could you share details? Could you dump the `hw_params` when the device is playing something from some other source? You might need to hunt for your actual card, but try along these lines: ``` cat /proc/asound/card0/pcm0p/info cat /proc/asound/card0/pcm0p/sub0/info cat /proc/asound/card0/pcm0p/sub0/hw_params ``` My guess would be that it doesn't support the predefined buffer size utilised in the current alsa implementation. Should probably add in a check against [`snd_pcm_hw_params_get_buffer_size_max`](https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#ga3caf61ab086028067b602d48182df708) to avoid this.
Author
Owner

@Madvih commented on GitHub (Apr 24, 2019):

hey, thanks for the reply. I will post it right when I get home from work. I tried to look into this params, but I don't have the knowlage for this yet, need to study it more deep to understand that, meanwhile I turned for help here.

<!-- gh-comment-id:486152482 --> @Madvih commented on GitHub (Apr 24, 2019): hey, thanks for the reply. I will post it right when I get home from work. I tried to look into this params, but I don't have the knowlage for this yet, need to study it more deep to understand that, meanwhile I turned for help here.
Author
Owner

@Madvih commented on GitHub (Apr 24, 2019):

I manage it to work, actualy pulseaudio did. I found similar problem from last year, guy in the topic talks about bad audio drivers for his VERO 4k sound card and hes got it work by setting up pulseaudio. I did the same and it's now working after countless hours of pain :D.

There is a new error msg now, but it's playing good through SPDIF output. Thanks bud!

image

<!-- gh-comment-id:486310203 --> @Madvih commented on GitHub (Apr 24, 2019): I manage it to work, actualy pulseaudio did. I found similar problem from last year, guy in the topic talks about bad audio drivers for his VERO 4k sound card and hes got it work by setting up pulseaudio. I did the same and it's now working after countless hours of pain :D. There is a new error msg now, but it's playing good through SPDIF output. Thanks bud! ![image](https://user-images.githubusercontent.com/13177711/56675326-20b30a00-66bc-11e9-89c5-aeaffce67893.png)
Author
Owner

@kingosticks commented on GitHub (Apr 24, 2019):

@Madvih Were you just using the Pi's HDMI output or some other audio board? It's great you have a workaround but we need to recreate this issue and fix it. The hw_param values would have been useful.

<!-- gh-comment-id:486322078 --> @kingosticks commented on GitHub (Apr 24, 2019): @Madvih Were you just using the Pi's HDMI output or some other audio board? It's great you have a workaround but we need to recreate this issue and fix it. The hw_param values would have been useful.
Author
Owner

@Madvih commented on GitHub (Apr 24, 2019):

I'm glad to give you any information you need to fix it.

image

image

<!-- gh-comment-id:486390356 --> @Madvih commented on GitHub (Apr 24, 2019): I'm glad to give you any information you need to fix it. ![image](https://user-images.githubusercontent.com/13177711/56687370-654b9f00-66d6-11e9-806c-d1d0ce07ef70.png) ![image](https://user-images.githubusercontent.com/13177711/56687531-cd9a8080-66d6-11e9-9b49-ee97541a3f2a.png)
Author
Owner

@Madvih commented on GitHub (Apr 24, 2019):

BTW this information could help too. This thread sovle the problem for me and has same problem, more detailed written.

here

<!-- gh-comment-id:486393222 --> @Madvih commented on GitHub (Apr 24, 2019): BTW this information could help too. This thread sovle the problem for me and has same problem, more detailed written. [here](https://discourse.osmc.tv/t/audio-driver-bug/71228)
Author
Owner

@kingosticks commented on GitHub (Apr 24, 2019):

When I see raspotify I keep mistakingly assuming it's a raspberry pi. So this is vero4k and whatever soundcard (AML M8 audio) that thing has. We'd specifically need the hw_params output when it's trying to play in the broken state, which I guess is no longer available since its fixed. Oh well.

<!-- gh-comment-id:486395476 --> @kingosticks commented on GitHub (Apr 24, 2019): When I see raspotify I keep mistakingly assuming it's a raspberry pi. So this is vero4k and whatever soundcard (AML M8 audio) that thing has. We'd specifically need the hw_params output when it's trying to play in the broken state, which I guess is no longer available since its fixed. Oh well.
Author
Owner

@kingosticks commented on GitHub (Apr 24, 2019):

Yeh that does help, specially:

AMLogic do not provide a full ALSA driver so if MPD needs to access the soundcard via ALSA it will struggle.

So Yeh. They've got buggy software which they don't seem too bothered about fixing, presumably cause it's outside the scope of the product they sell - fair enough. We can close this, we don't need to worry about a half-baked sound driver.

<!-- gh-comment-id:486397282 --> @kingosticks commented on GitHub (Apr 24, 2019): Yeh that does help, specially: > AMLogic do not provide a full ALSA driver so if MPD needs to access the soundcard via ALSA it will struggle. So Yeh. They've got buggy software which they don't seem too bothered about fixing, presumably cause it's outside the scope of the product they sell - fair enough. We can close this, we don't need to worry about a half-baked sound driver.
Author
Owner

@Madvih commented on GitHub (Apr 24, 2019):

Yeh that does help, specially:

AMLogic do not provide a full ALSA driver so if MPD needs to access the soundcard via ALSA it will struggle.

So Yeh. They've got buggy software which they don't seem too bothered about fixing, presumably cause it's outside the scope of the product they sell - fair enough. We can close this, we don't need to worry about a half-baked sound driver.
I purged pulseaudio and change it to previous (not working) status, if you are still interested in that data. Just tell me what to write in console... or if I can close this.

<!-- gh-comment-id:486399984 --> @Madvih commented on GitHub (Apr 24, 2019): > Yeh that does help, specially: > > > AMLogic do not provide a full ALSA driver so if MPD needs to access the soundcard via ALSA it will struggle. > > So Yeh. They've got buggy software which they don't seem too bothered about fixing, presumably cause it's outside the scope of the product they sell - fair enough. We can close this, we don't need to worry about a half-baked sound driver. I purged pulseaudio and change it to previous (not working) status, if you are still interested in that data. Just tell me what to write in console... or if I can close this.
Author
Owner

@kingosticks commented on GitHub (Apr 24, 2019):

That's kind of you to do that but personally I'm all for closing this now. Probably isn't anything we can do.

<!-- gh-comment-id:486400743 --> @kingosticks commented on GitHub (Apr 24, 2019): That's kind of you to do that but personally I'm all for closing this now. Probably isn't anything we can do.
Author
Owner

@Madvih commented on GitHub (Apr 24, 2019):

Yeah gotcha, but big thanks for help anyway, your quick answers and keen to help me is much appreciated. If this was different kind of problem, I'm sure of that, you would help me to resolve it quickly! Thanks and have a good night!

<!-- gh-comment-id:486402213 --> @Madvih commented on GitHub (Apr 24, 2019): Yeah gotcha, but big thanks for help anyway, your quick answers and keen to help me is much appreciated. If this was different kind of problem, I'm sure of that, you would help me to resolve it quickly! Thanks and have a good night!
Author
Owner

@markerdmann commented on GitHub (Apr 3, 2020):

@kingosticks I'm currently getting the same error:

[2020-04-03T07:52:56Z ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'
[2020-04-03T07:52:56Z ERROR librespot_playback::player] Could not start audio: Alsa error: PCM open failed

In my case, I'm running on Arch with jack audio.

<!-- gh-comment-id:608288707 --> @markerdmann commented on GitHub (Apr 3, 2020): @kingosticks I'm currently getting the same error: ``` [2020-04-03T07:52:56Z ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument' [2020-04-03T07:52:56Z ERROR librespot_playback::player] Could not start audio: Alsa error: PCM open failed ``` In my case, I'm running on Arch with jack audio.
Author
Owner

@ashthespy commented on GitHub (Apr 3, 2020):

@markerdmann could you add the info from https://github.com/librespot-org/librespot/issues/333#issuecomment-486148173 so we can look at what the expected hw_parameters should be?

Also, it would seem that your using the alsa backend, and not jack?

<!-- gh-comment-id:608356277 --> @ashthespy commented on GitHub (Apr 3, 2020): @markerdmann could you add the info from https://github.com/librespot-org/librespot/issues/333#issuecomment-486148173 so we can look at what the expected `hw_parameters` should be? Also, it would seem that your using the alsa backend, and not jack?
Author
Owner

@markerdmann commented on GitHub (Apr 4, 2020):

@ashthespy Yes, I'll run those commands and post the info here.

After I posted my comment, I noticed librespot has a jack backend. I recompiled and tried running it with the jack backend, but for some reason I'm not hearing any audio or seeing any librespot errors. I'll try running it again in verbose mode.

This is my current setup:

With that setup, audio is working with:

  • Firefox
  • Chrome
  • mplayer
  • vlc (with jack or alsa as the output module)
  • spotify (but it's flakey -- sometimes it freezes up)

It's not working with:

  • librespot and spotifyd (same error)
<!-- gh-comment-id:608952047 --> @markerdmann commented on GitHub (Apr 4, 2020): @ashthespy Yes, I'll run those commands and post the info here. After I posted my comment, I noticed librespot has a jack backend. I recompiled and tried running it with the jack backend, but for some reason I'm not hearing any audio or seeing any librespot errors. I'll try running it again in verbose mode. This is my current setup: - Mostly vanilla arch (latest) with xmonad - alsa and jack (qjackctl) - I'm using the basic /etc/asound.conf recommended here: https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit#Playing_nice_with_ALSA - My USB audio card is a Topping DX3Pro, and I've updated my /usr/share/alsa/alsa.conf to make that card (index 2) the alsa default. With that setup, audio is working with: - Firefox - Chrome - mplayer - vlc (with jack or alsa as the output module) - spotify (but it's flakey -- sometimes it freezes up) It's not working with: - librespot and spotifyd (same error)
Author
Owner

@markerdmann commented on GitHub (Apr 4, 2020):

@ashthespy Here's the output for those three commands:

sendrecv@dogen ~/a/l/t/release (dev)> cat /proc/asound/card2/pcm0p/info
card: 2
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
sendrecv@dogen ~/a/l/t/release (dev)> cat /proc/asound/card2/pcm0p/sub0/info
card: 2
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
sendrecv@dogen ~/a/l/t/release (dev)> cat /proc/asound/card2/pcm0p/sub0/hw_params 
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2048
buffer_size: 8192

Is there something else I should print out for the jack device that I see in aplay -L? I'm pretty sure that's the device librespot is trying to play to, because I see the following behavior:

  1. With --backend alsa and no --device, I get the snd_pcm_hw_params_set_buffer_size_near error.
  2. With --backend alsa and --device "sysdefault:CARD=Pro" I get Alsa error PCM open ALSA function 'snd_pcm_open' failed with error 'EBUSY: Device or resource busy'.

These are my qjackctl settings:

image
image

<!-- gh-comment-id:608954762 --> @markerdmann commented on GitHub (Apr 4, 2020): @ashthespy Here's the output for those three commands: ``` sendrecv@dogen ~/a/l/t/release (dev)> cat /proc/asound/card2/pcm0p/info card: 2 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 sendrecv@dogen ~/a/l/t/release (dev)> cat /proc/asound/card2/pcm0p/sub0/info card: 2 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 sendrecv@dogen ~/a/l/t/release (dev)> cat /proc/asound/card2/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 2048 buffer_size: 8192 ``` Is there something else I should print out for the jack device that I see in `aplay -L`? I'm pretty sure that's the device librespot is trying to play to, because I see the following behavior: 1. With `--backend alsa` and no `--device`, I get the `snd_pcm_hw_params_set_buffer_size_near` error. 2. With `--backend alsa` and `--device "sysdefault:CARD=Pro"` I get `Alsa error PCM open ALSA function 'snd_pcm_open' failed with error 'EBUSY: Device or resource busy'`. These are my qjackctl settings: ![image](https://user-images.githubusercontent.com/187540/78416402-22848d80-75ee-11ea-9a15-2b2fe0a8586e.png) ![image](https://user-images.githubusercontent.com/187540/78416408-2ca68c00-75ee-11ea-8d5d-27e2965dbc77.png)
Author
Owner

@markerdmann commented on GitHub (Apr 4, 2020):

I read this issue https://github.com/librespot-org/librespot/issues/195 and it sounds like the alsa and jack backends are potentially being deprecated in favor of the rodio backend?

I tried recompiling with the rodio backend, and that's working on my system. 👍

<!-- gh-comment-id:608990452 --> @markerdmann commented on GitHub (Apr 4, 2020): I read this issue https://github.com/librespot-org/librespot/issues/195 and it sounds like the alsa and jack backends are potentially being deprecated in favor of the rodio backend? I tried recompiling with the rodio backend, and that's working on my system. :+1:
Author
Owner

@thexperiments commented on GitHub (Apr 29, 2021):

Necro tip. I got it working with my DAC which has show the same errors by using --device "plughw:2,0" instead of --device "hw:2,0". As I understand it this way the alsa plugins are involved and can convert if necessary, for my dac it seems that it only supported a bit depth of 32 bit. (Topping DX3 Pro)

<!-- gh-comment-id:829627083 --> @thexperiments commented on GitHub (Apr 29, 2021): Necro tip. I got it working with my DAC which has show the same errors by using ``--device "plughw:2,0"`` instead of ``--device "hw:2,0"``. As I understand it this way the alsa plugins are involved and can convert if necessary, for my dac it seems that it only supported a bit depth of 32 bit. (Topping DX3 Pro)
Author
Owner

@roderickvd commented on GitHub (Apr 30, 2021):

Necro tip. I got it working with my DAC which has show the same errors by using --device "plughw:2,0" instead of --device "hw:2,0". As I understand it this way the alsa plugins are involved and can convert if necessary, for my dac it seems that it only supported a bit depth of 32 bit. (Topping DX3 Pro)

That's a good solution. Also in the upcoming librespot release there's native support for 32-bit output, so you could try that and have better sound quality to boot. It's in dev right now if you want to give it a spin.

<!-- gh-comment-id:830241409 --> @roderickvd commented on GitHub (Apr 30, 2021): > Necro tip. I got it working with my DAC which has show the same errors by using `--device "plughw:2,0"` instead of `--device "hw:2,0"`. As I understand it this way the alsa plugins are involved and can convert if necessary, for my dac it seems that it only supported a bit depth of 32 bit. (Topping DX3 Pro) That's a good solution. Also in the upcoming `librespot` release there's native support for 32-bit output, so you could try that and have better sound quality to boot. It's in `dev` right now if you want to give it a spin.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#217
No description provided.