mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #864] Tracks pauses constantly on first play #433
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#433
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 @jessicah on GitHub (Oct 11, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/864
Originally assigned to: @roderickvd on GitHub.
Once cached, it's fine, but the first time playing a track, it always has pauses.
@roderickvd commented on GitHub (Oct 11, 2021):
Well that's something that myself and most others can't reproduce, or we would be swamped with such issues.
Are you sure that your network connection is in order (so that it can buffer fast enough?)
Does it also happen with cache disabled?
@jessicah commented on GitHub (Oct 11, 2021):
Actually, I noticed one error message on screen before disappearing of a buffer underrun. Am using the ALSA back-end. I don't have this with other apps, such as Kodi.
@roderickvd commented on GitHub (Oct 12, 2021):
Could you provide the full verbose logs as well as answers to my questions above?
@jessicah commented on GitHub (Oct 12, 2021):
The error was persistent with
ncspot. I hadn't had the issue for librespot for about an hour or so, but now it's started happening in librespot too. Unfortunately, I'm not getting any ALSA specific errors from librespot.And the buffer underruns are occurring after the
saving to cachemessage.I've just tried playing the same track with
--disable-audio-cacheand the buffer underruns are continuing with this particular track.And now it's gone from no buffer underruns to an underrun storm :-/ Also, both
ncspotandlibrespotconsistently use around 50% of a CPU core on my system, which seems excessive, is that normal?@roderickvd commented on GitHub (Oct 13, 2021):
No. Find the cause of this issue and you will likely find your solution. Your system is bogged and this is causing I/O underruns.
First to be sure, was this compiled with the
--releaseflag?Second the Alsa period size of 4096 seems very small, doesn't it @JasonLG1979?
What is your Alsa output device?
Please post:
librespotwithlibrespot@JasonLG1979 commented on GitHub (Oct 13, 2021):
@jessicah your log messages say 1024 frames per period and a 4096 frame total buffer size. That's your problem. It's either a driver or configuration issue. Librespot by default asks for 5, 100ms periods (4410 frames a period for a total buffer size of 22050 frames). Asks being the operative word. Your system for some reason is providing less than a 1/4 of the buffer that librespot is asking for.
@JasonLG1979 commented on GitHub (Oct 13, 2021):
In addition to what @roderickvd is asking for I'd also like to see the output of:
aplay -Dxxx --dump-hw-params /usr/share/sounds/alsa/Front_Right.wavWhere
-Dxxxis the output you've specified for librespot so for example-Dhw:0,0. If you haven't specified an output you can omit-Dso it would just beaplay --dump-hw-params /usr/share/sounds/alsa/Front_Right.wav@jessicah commented on GitHub (Oct 13, 2021):
It's highly probable that my ALSA config needs tweaking, I copied from some help page as it didn't work out of the box when setting up Kodi, and it's a headless Ubuntu install.
launch:
/home/jessica/source/librespot/target/debug/librespot -n Librespot -b 320 -c ./cache --device-type avr --verbose --autoplayALSA config:
librespot log:
aplay hardware params (default):
aplay hardware params (actual device):
@jessicah commented on GitHub (Oct 13, 2021):
Using the
hw:0,3device directly improves the situation a bit, but am still running into what I presume are still buffer underruns.Latest output:
@roderickvd commented on GitHub (Oct 14, 2021):
I'm inclined to close this issue, because it's likely a system configuration issue and not a
librespotbug. Your Alsadmixconfiguration is what specifies the low 4096 period size, so that's not right.It was good idea to test with the direct hardware device. Did you compile with
--release? Otherwise debug code will be enabled, and the performance impact with dithering enabled is huge to the point that it drags platforms like Raspberry Pi's down.Note to self: should check for
#[cfg(debug_assertions)]to have the verbose log print whether we're in debug or release.@JasonLG1979 commented on GitHub (Oct 14, 2021):
Yep, that's your problem for sure. You may be able to get away with a buffer that small on an x86-64 system but that will hammer a Raspberry Pi, and for no good reason either. Buffers that small are really only needed for multi-track recording. You really don't need super low latency just for playback. Worst case with a good sized buffer during playback is that you need to delay video to match the audio a little bit. Kodi has something in it's settings I'm sure somewhere for syncing the audio.
Try this and see if it works:
hw:0,3says it can doS32_LEso I'd use that. Librespot will outputS32_LEif you add--format S32the main advantage of 32 bit is that you get more or less lossless software volume control. Anything that not 32 bit will just get padded with zeros at pretty much no performance cost and no audio quality cost.If you were getting underruns it would say so in the logs. Debug builds tend to run pretty poorly on a Raspberry Pi. Unless you're developing and you want to test something real quick you should be using the
--releaseflag so the binary is optimized. What you want is:cargo build --release --no-default-features --features alsa-backend@jessicah commented on GitHub (Oct 15, 2021):
Even with @JasonLG1979's config, I'm still getting playback issues (with release build), seems buffers are still small?
2021-10-15T00:12:00Z TRACE librespot_playback::player] == Starting sink ==
[2021-10-15T00:12:00Z TRACE librespot_playback::audio_backend::alsa] Frames per Buffer: 8192
[2021-10-15T00:12:00Z TRACE librespot_playback::audio_backend::alsa] Frames per Period: 4096
[2021-10-15T00:12:00Z TRACE librespot_playback::audio_backend::alsa] Period Buffer size in bytes: 32768
[2021-10-15T00:12:00Z TRACE librespot_playback::audio_backend::alsa] Period Buffer capacity: 32768
@JasonLG1979 commented on GitHub (Oct 15, 2021):
Try changing it to:
@JasonLG1979 commented on GitHub (Oct 15, 2021):
@roderickvd it may be time to make period size and the number of periods user configurable. It could default to what we have which is 5 periods at 100ms and have a reasonable range, say 2 - 10 periods (there has to be at least 2 periods per buffer) and 10 - 200ms periods. It could be
--alsa-buffer-periodsand--alsa-buffer-period-sizeWhat we have works for 99% of people but this is the 2nd edge case in a couple months.
@roderickvd commented on GitHub (Oct 15, 2021):
aplayoutput indicates that thehw:0,3device supports the right range of periods.So I still don't understand what's going on here.
dmixand that's used as the output device?plughw?S16orS32here? Please continue to post full command lines and verbose logs, not excerpts.Would like to see more debugging before we overhaul anything or introduce more command line options. In fact I'm still not convinced that it's
librespotand not the host platform.@JasonLG1979 commented on GitHub (Oct 15, 2021):
That just tells us a range of number of periods and sizes it doesn't tell us which actually work together. Not all number of periods work with all period sizes.
@JasonLG1979 commented on GitHub (Oct 15, 2021):
If I knew what the device was (I think it might be one of the HDMI ports given that it's
hw:0,3) we could look at the driver source and see what the deal is maybe?@JasonLG1979 commented on GitHub (Oct 15, 2021):
Both her and I's configs already use dmix.
I guess I assumed a Raspberry Pi of some kind?
@roderickvd commented on GitHub (Oct 15, 2021):
That's certainly true.
It's not clear to me whether
librespotis now launched with--device dmixor--device hw:0,3.@JasonLG1979 commented on GitHub (Oct 15, 2021):
She said:
I think her device may just be finicky. It seems to be able to do a 0.5 sec buffer with 2 periods and a 4 period buffer with really small periods. Neither of which seems to work very well. It may just be a matter of trial and error to see if we can come up with something that works?
@kingosticks commented on GitHub (Oct 15, 2021):
I think (not 100% sure) that
in the first suggested config are actually specifying bytes (not frames, like I think you wanted. And yes this is at odds with the terminology used by --dump-hw-params). Perhaps that explains why it cannot comply with what librespot is asking for?
@JasonLG1979 commented on GitHub (Oct 15, 2021):
Derp de derp. You're right... 🤦
@JasonLG1979 commented on GitHub (Oct 15, 2021):
Then I would maybe suggest:
And change:
Until you find something that works.
@roderickvd commented on GitHub (Oct 15, 2021):
Good catch. Not surprised about yet another Alsa idiosyncrasy!
@JasonLG1979 commented on GitHub (Oct 15, 2021):
I should have caught that. That's my bad. The derp is strong with this one...
@kingosticks commented on GitHub (Oct 15, 2021):
To be honest I am still not sure, the online alsa docs and the source code have conflicting comments! Probably safest to avoid using it if possible and go with buffer_time instead, if you have to specify it for some reason.
@roderickvd commented on GitHub (Oct 21, 2021):
Any progress on this @jessicah?
@jessicah commented on GitHub (Nov 3, 2021):
Sorry, I'll give the suggestions a go now, been moving stuff, and haven't had a chance to retest. It's an Intel NUC i3-4010U, audio via HDMI.
@jessicah commented on GitHub (Nov 3, 2021):
Well, it seems it's a weird ALSA bug. Running
aplay -D hw:0,3 --verbose ~/test.wavgives the same issues, so I don't understand how Kodi can play audio without any hiccups. I tried passing several parameters for buffer/period size/time, but they all seem to get ignored byaplay.For reference, here is output from aply with the last suggested configuration:
And without specifying a device explicitly:
So I guess may as well close this? I'm not sure what else I can do, especially when Kodi doesn't have any issues :-/
@roderickvd commented on GitHub (Nov 4, 2021):
One last thing you could check is version
0.1.6and0.2.0. Those versions approached the Alsa buffers slightly different. If either one of those work, then it's worth a discussion whether we should go back to that -- although I'd prefer not to. Anyway before we get there, it'd be nice if you could report back on that.@JasonLG1979 commented on GitHub (Nov 4, 2021):
I think it may be a case of the device only accepting a very small set of a combination of buffer size, period size, number of periods parameters as even
aplayis having trouble with it. As I've said it may just be a matter of experimenting with different values.I'll see if I can't have a look at Kodi's source and see what they're doing.
@JasonLG1979 commented on GitHub (Nov 4, 2021):
Yep, they seem to iterate though buffer and period size combinations.
github.com/xbmc/xbmc@a0d424ec8f/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp (L758-L793)We can do the same. Basically start at a desired buffer and period size and loop though until we get something that sticks.
@roderickvd commented on GitHub (Nov 4, 2021):
Good catch. Just some more lines to work around Alsa weirdness! Fondly remember the Alsa mixer rewrite. 🤭
@JasonLG1979 commented on GitHub (Nov 4, 2021):
@roderickvd This monstrosity seems to do the trick:
@JasonLG1979 commented on GitHub (Nov 4, 2021):
@jessicah try this branch and see how it works. It kinda sorta emulates what Kodi does.
@roderickvd commented on GitHub (Nov 5, 2021):
Either that or the hardware device (Intel?) is really iffy. What bothers me about Alsa is that it doesn't help you making these hardware idiosyncracies transparent, that you have to solve them yourself in userspace. Just blowing off steam though, it's the best thing we have in terms of bare metal performance... which means you also have to deal with bare metal.
Thanks for that patch. If it checks out with @jessicah we should vet it against various hardware configurations. Who knows, some Alsa drivers may incorrectly report MAX as 0 or other weird stuff we haven't thought of.
@JasonLG1979 commented on GitHub (Nov 5, 2021):
That would be extremely broken and wouldn't work at all as ALSA sits on the bottom of every Linux audio stack be it Jack, PulseAudio or PipeWire or any app or framework that sits on top of those. ALSA is the bottom of the bottom layer unless you're really dealing with real bare metal on like an embedded system like a micro controller or something.
@JasonLG1979 commented on GitHub (Nov 8, 2021):
@jessicah Still waiting for you to test out that branch. You're the only one that can tell us if it works on your hardware as it represents an edge case that is impossible for someone without that specific hardware to reproduce. I can confirm that it works for me on everything I own but then again the current code in the master and dev branches work just fine too so that doesn't really say anything besides that my experimental changes don't break anything on my specific hardware.
@JasonLG1979 commented on GitHub (Dec 4, 2021):
Just going to bump this issue one last time to make sure it didn't fall though the cracks @jessicah?
@roderickvd I'd say this is very similar to https://github.com/librespot-org/librespot/issues/895 in that they both seem to be misbehaving devices, misbehaving in different ways but still misbehaving.
https://github.com/librespot-org/librespot/pull/896 would probably be about as close as we can get to "fixing" this issue also. When I say "fixing" I mean do our best and if that's not good enough use the device's default. Which is basically what Kodi does.
In any event I'd close this after whatever amount of time you decide is appropriate after this comment if @jessicah for whatever reason has not responded to requests to test possible solutions.
@roderickvd commented on GitHub (Jan 12, 2022):
No feedback and probably fixed; closing.