mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1274] sound volume issue librespot/snapserver #584
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#584
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 @ArneKlaver on GitHub (Apr 11, 2024).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1274
Not sure if this issue is with Librespot or snapserver
When running librespot in snapserver conf
source = librespot:///usr/bin/librespot?name=Spotify&devicename=Keuken &autoplay=true &volume=75 &bitrate=320 &sampleformat=44100:16:2 &codec=flac
(I tried a lot of different volume settings nothing seemed to help)
I have the issue that when skipping songs sometimes the sound gets boosted extremely loud. This sounds like static noise but if you lower the Spotify volume to almost 0% you notice the sound is normal again but very loud.
I tested this on the snapweb , phone client and snapclient on the server itself all have the same issue.
I am running the raspotify fork on a raspbery pi zero 2 w
raspotify uses librespot 0.4.2 a6e1258 (Built on 2023-06-21, Build ID: zuwVQKTQ, Profile: release)
I tried running librespot seperate now to a fifo file and make snapserver catch that stream. Like this post https://www.reddit.com/r/linuxaudio/comments/152vmtk/comment/kw41o5w/?share_id=CXMPHgak5LGL0HXpcZW-R&utm_content=2&utm_medium=android_app&utm_name=androidcss&utm_source=share&utm_term=1
This seems to work without issues.
I could not find any logs
Host (what you are running
librespoton):@isolatedvirus commented on GitHub (Apr 23, 2024):
FWIW that volume setting in the source definition for snapserver is for the initial volume setting of librespot when a client connects. Try removing the codec statement from the source definition, as well as trying codec=pcm
@giggywithit commented on GitHub (Jun 2, 2024):
I figured that this could be a better place to post my request, rather than open another post.
I use this initial volume setting myself.
Is there a way to set it so that after a period of time of the player being idle, say 20 minutes, this initial setting gets reapplied if the volume is currently higher than the value set for initial volume? Sometimes while playing, as the night gets later and there's periods of time with the player sitting ldle, it will startle me to start it back up when the volume was high and forgotten about. It would be nice that if the volume is currently set lower than the initial, and an idle time for any duration, to stay playing lower. I have tried making a script that sets the volume through alsa, but when i control through my phone or other, the setting is still at whatever it was last and then will still jump to the last volume as soon as i adjust it on the app. When it's been idle and still volume high, it's very abrupt and startling when playing another track.
There is only one other feature request if it was ever possible, and that is the ability to add 1 second of silence track before the actual track gets played, this when librespot is first started, and then each time the player sets idle for 20 minutes or more, like my reasoning above. My reasoning is that I have an amplifier that starts up and takes 1 second to do so. It turns itself off after 20 minutes and repeats upon startup.
Does this make any sense?
Is there any way to achieve what I am looking for?
Thx
@codesalatdev commented on GitHub (Sep 16, 2024):
Did using pcm as a codec fix this for you? I am also facing this issue and it's rather hard to reproduce random issues like this.
@ArneKlaver commented on GitHub (Sep 16, 2024):
Sorry I currently dont have the setup anymore to test.
I worked around this by creating a seperate raspotify stream and have snapcast read this file
for each stream you want create a librespot service:
(Make sure the fifo file is created beforehand. If you let one of the programmes make it there is an issue with pausing a song. it keeps going….)
And in the snapserver config use this file to get spotify in snapcast with:
source = pipe:///home/pi/spotifyTMP/spotifyKeuken/snapfifo_spotify_keukenname=Spotify_Keuken&mode=read&sampleformat=44100:16:2&bitrate=320
@roderickvd commented on GitHub (Sep 16, 2024):
Please try with native librespot. We don't support raspotify or its own librespot fork - issues specific to that should be filed there.
@codesalatdev commented on GitHub (Sep 16, 2024):
This issue is still valid as I am not using raspotify. I am compiling librespot from source and using it as a source in snapcast.
@roderickvd commented on GitHub (Sep 16, 2024):
OK. Can you try running librespot with snap or anything else?
@codesalatdev commented on GitHub (Sep 16, 2024):
Thank you a lot for that! I will try using file streams as soon as I get home again and report back.
@codesalatdev commented on GitHub (Sep 16, 2024):
Took me a second to realize you mean packaged versions and weren't referencing snapcast :D I certainly can although I will only be able to test this Thursday with the same setup.
I feel like this is caused by some combination of software and not librespot itself but I will definitely look into it further.
@roderickvd commented on GitHub (Sep 16, 2024):
Sorry for the confusion, I did mean to say without snap. Just plain compiled from source, nothing strapped on top.
@codesalatdev commented on GitHub (Sep 17, 2024):
Then I will try running it on the same system and direct output to the speakers as soon as I can
@codesalatdev commented on GitHub (Sep 19, 2024):
I am not able to reproduce this issue with librespot alone. Not with the Rodio backend, not with the alsa backend, not even with the pipe backend directly piped to alsa (to simulate how snapcast receives data).
I AM able to reproduce this with snapcast pretty accurately now, with me only needing to skip ~3 songs for the speakers to go full blast.
Setting the codec to pcm - like @isolatedvirus suggested - DOES fix the issue, although I do not know why; I am not familiar with the inner workings of snapcast and do not know why it shouldn't expect pcm from librespot by default.Edit: it does NOT fix the issueI will file an issue with snapcast and reference this issue there.
@othiman commented on GitHub (Sep 19, 2024):
This problem sounds familiar. There were already these tickets which did follow the problem:
https://github.com/librespot-org/librespot/issues/1218
https://github.com/badaix/snapcast/issues/1170
It seems that version 0.28.0 of snapcast should contain a fix for this. What version do you use @codesalatdev?
@codesalatdev commented on GitHub (Sep 19, 2024):
Okay, you're right, I didn't see #1218 when searching for issues; probably because it doesn't mention skipping songs.
I was on 0.27.0 and just upgraded. I don't want to jump the gun like I did with the pcm codec, so I will try breaking it for a little longer and report back. It seems like I found this issue and assumed it was librespot that is misbehaving.
@roderickvd commented on GitHub (Sep 19, 2024):
Alright, closing this one then. Thanks.