mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #333] No audio - problem #217
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#217
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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
@ashthespy commented on GitHub (Apr 24, 2019):
Curious to know what your output device is - could you share details? Could you dump the
hw_paramswhen the device is playing something from some other source?You might need to hunt for your actual card, but try along these lines:
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_maxto avoid this.@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.
@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!
@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.
@Madvih commented on GitHub (Apr 24, 2019):
I'm glad to give you any information you need to fix it.
@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
@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.
@kingosticks commented on GitHub (Apr 24, 2019):
Yeh that does help, specially:
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.
@Madvih commented on GitHub (Apr 24, 2019):
@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.
@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!
@markerdmann commented on GitHub (Apr 3, 2020):
@kingosticks I'm currently getting the same error:
In my case, I'm running on Arch with jack audio.
@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_parametersshould be?Also, it would seem that your using the alsa backend, and not jack?
@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:
It's not working with:
@markerdmann commented on GitHub (Apr 4, 2020):
@ashthespy Here's the output for those three commands:
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:--backend alsaand no--device, I get thesnd_pcm_hw_params_set_buffer_size_nearerror.--backend alsaand--device "sysdefault:CARD=Pro"I getAlsa error PCM open ALSA function 'snd_pcm_open' failed with error 'EBUSY: Device or resource busy'.These are my qjackctl settings:
@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. 👍
@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)@roderickvd commented on GitHub (Apr 30, 2021):
That's a good solution. Also in the upcoming
librespotrelease there's native support for 32-bit output, so you could try that and have better sound quality to boot. It's indevright now if you want to give it a spin.