mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #197] no sound output (most of the time) #134
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#134
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 @idevsoftware on GitHub (Apr 1, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/197
Hi, I built librespot with the hope of having a spotify connect client on my linux arcade cab. It seems to work fine since it connects, authenticates and shows other clients (like my desktop computer and mobile phone). Whenever I try to play a track, however, it loads and the remote client shows it as it's playing, but I get no sound most of the time. The few times it works I only get sound for a few seconds (tipically 2-3, sometimes for a fraction of a second), but most of the time no sound at all. Also when this happens I am unable to quit librespot (ctrl+c) and I have to kill the process instead.
I am attaching the output from a session on which I got no sound at all. Note at the end how it gets the
^Cand the last message isShutting down player thread ..., however it stays there indefinitely without ever returning control.librespot.log
@machsFuel commented on GitHub (Apr 1, 2018):
I've had similar problems, have you tried muting and unmuting your alsa outputs?
@ComlOnline commented on GitHub (Apr 11, 2018):
I think I've had this as well I thought it was some thing I had done elsewhere. Ill look tonight and see if I can reproduce it again.
@lrbalt commented on GitHub (Apr 30, 2018):
From the ALSA errors I think you have a configuration issue on your Linux system. Those errors are not from Librespot but from portaudio calling into ALSA.
A fix was merged today to better respond to Ctrl-C. But your problem could be that Librespot hangs on ALSA not working properly.
@idevsoftware commented on GitHub (Apr 30, 2018):
hi @lrbalt, thanks for your response. I don't think that's the case since I know alsa is correctly configured, with every other audio app on my system being able to play sound without any issues. I'll try building with the newly merged code you mention and take a second look at my alsa conf later today, I'll let you know how it goes.
@lrbalt commented on GitHub (Apr 30, 2018):
Ok, please look at your pulse audio config too, or try using the ALSA backend instead of pulseaudio
@idevsoftware commented on GitHub (Apr 30, 2018):
I don't use pulse audio at all, just plain old alsa
@lrbalt commented on GitHub (Apr 30, 2018):
Sorry, I meant portaudio which is mentioned in your log. If you only use ALSA, you can change backend in Config.toml
@idevsoftware commented on GitHub (Apr 30, 2018):
Gotcha. But isn't portaudio actually required by librespot as a cross-platform, higher level audio interface?
@lrbalt commented on GitHub (Apr 30, 2018):
It is not required afaics. Idk
@idevsoftware commented on GitHub (May 5, 2018):
ok, so a few updates. I just pulled the latest version and rebuilt. ctrl+c now works as expected, and switching to the ALSA backend (as opposed to PortAudio) solved the audio issue. However there is a noticeable delay between what the Spotify client says and what's playing: when playing a song it can take about 15 seconds for it to actually play, but the client time mark starts moving ahead as soon as I hit 'play'. Also, play/pause commands have a delay of about 2-3 seconds. FWIW I'm testing with the iPhone Spotify App as client, connected to my home Wi-Fi network. The machine where the librespot client is running is directly hooked up to the same LAN segment via Ethernet. I don't have any other noticeable delays on regular network operations from the same computer.
@roderickvd commented on GitHub (May 25, 2021):
If it was silent on PortAudio, then it's likely that PA opened audio output in some format other than 16-bit signed integer. There's been a lot of development since this issue was reported, so I'm closing this for now but feel free to re-open if the issue persists.