mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #340] Pipe plays too fast #224
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#224
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 @dflvunoooooo on GitHub (Jun 21, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/340
If I redirect the librespot output via pipe to a fifo file the music is a little bit to fast, just enough to notice and to nag. This happens as well with the
… --backend pipe >or with--backend pipe --device /tmp/snapfifo-Spotify.If I start librespot without the pipe option it plays in normal speed.
There is no error message nor anything wich would show a problem. I use librespot 12.1.51-7 on a Arch Linux desktop.
Has anyone an idea how to solve this issue? I would like to run librespot on a headless server, wich will not have pulseaudio.
Edit: typo.
@kingosticks commented on GitHub (Jun 21, 2019):
When using the
pipebackend, raw PCM is written to the file as quickly as it's downloaded and it's entirely the job of the other side to handle playback i.e. snapcast's job.@dflvunoooooo commented on GitHub (Jun 25, 2019):
A I see. Thank you very much for pointing that out.
@dflvunoooooo commented on GitHub (Jul 1, 2019):
In case someone stumbles over this, the solution is to set the sample rate of snapcast to 44000Hz. I got help from here https://github.com/badaix/snapcast/issues/464#issue-460636537.
In my case it is now something like this
SNAPSERVER_OPTS="-s pipe:///tmp/snapfifo?name=snapcast&sampleformat=44000:16:2".@willstott101 commented on GitHub (Jul 1, 2019):
Glad you sorted it! I'm pretty sure that ought to be 44100 though technically.
@dflvunoooooo commented on GitHub (Jul 1, 2019):
Can you explain to me why?
@ashthespy commented on GitHub (Jul 1, 2019):
The ALSA implementation uses a 44100 sample rate..nevermind, we are talking about pipe here..I have been playing around with variable sample rates with lewton and ALSA after
github.com/RustAudio/lewton@dad57f2c71, but haven't gotten to testing it extensively. Should probably get some DACs that do variable rates and play around more...@dflvunoooooo commented on GitHub (Jul 1, 2019):
A interesting, didn't know that. Maybe I should get a metronome to check what works best.
@willstott101 commented on GitHub (Jul 1, 2019):
The decoded data from Spotify is always 16 bit 44.1kHz as far as I know. Does ogg support variable sample rates? I've never heard of that in audio before
@dflvunoooooo commented on GitHub (Jul 1, 2019):
Thank you.
Ogg does support variable bitrates, as far as I know. Or at least the vorbis codec.
Of what haven't you heard?
@kingosticks commented on GitHub (Jul 1, 2019):
That 44kHz fix is odd, I am surprised to hear that's required. That linked issue doesn't work for me.
Sample rate is not the same as bit rate. A variable sample rate would be odd. I've never heard of that being used either but I'd be interested to hear the reasoning behind it.
@kingosticks commented on GitHub (Jul 2, 2019):
Just to be clear for anyone else landing here, the correct sample rate to use is 44100, not 44000. So the snapcast setting would look like:
SNAPSERVER_OPTS="-s pipe:///tmp/snapfifo?name=snapcast&sampleformat=44100:16:2".From https://github.com/badaix/snapcast/issues/464#issuecomment-507621402