Conversation
The default period size on my system (Fedora Asahi, with PipeWire) is 220. This is much too short: it leads to lots of crackling even though the system itself is most certainly fast enough. Instead, request a period size that's a quarter of the buffer size. This fixes the crackling and should also reduce CPU consumption.
This is required when working on systems that have multiple players. Imagine that I have go-librespot for Spotify and mpd for local files: if I want to switch from one player to the other it's easier if they release the device when pausing so that the other one can takeover without them having to coordinate. |
|
Right, I see. I will update the PR to restore the previous behavior of closing and reopening the ALSA device on every pause/resume. (My personal opinion is that this should not be handled by applications, but rather by an audio server like PulseAudio or PipeWire. They are designed to fill this exact role. But I checked, and MPD indeed closes the audio device on pause when using the ALSA output). |
This is a partial rewrite of the ALSA output:
* Reading data from the source and writing data out to the ALSA device
is now done in a single goroutine. There's no internal ringbuffer
anymore.
* Instead of closing and reopening the ALSA device, it now uses
snd_pcm_drop and snd_pcm_prepare.
Thie main benefit is that when you pause, seek, and then resume the
audio, the audio of the previous playback position is no longer played
for a short bit. Even when pausing or seeking, the buffer wasn't getting
cleared. This was not super noticeable due to the relatively short
buffer size (80ms on my laptop, 160ms on my Raspberry Pi 3) but with the
previous commit increasing the period size this became _very_ noticeable
and grew to 2 seconds.
aykevl
force-pushed
the
alsa-period-size
branch
from
789993a to
435c88a
Compare
|
Updated to close and restore PCM on pause/resume. The behavior is still slightly different from what it was before in a different way: it is now only opened when it is first resumed (so it isn't opened directly after connecting to go-librespot). This is consistent with mpd for example and makes more sense to me, because it won't lead to unexpected "ALSA device is busy" errors after connecting but not playing any music. Tested it to confirm it still works fine and still fixes the two issues in the PR description. I've also updated my Raspberry Pi so that I'll be running this code whenever I'm playing music there for more extensive testing. |
2 participants
This PR fixes two main issues:
I suspect this is the root cause of https://community.volumio.com/t/new-2023-spotify-plugin/63381/354
An easy way to test this bug is to play a loud part of a song, pause, seek to a quiet part (the beginning is usually quiet), and resume. Before this PR, there was a bit of a stutter. After this PR, the stutter is gone entirely.
Note that this PR doesn't close/reopen the output device anymore on every pause/resume. I don't know whether anybody relied on this behavior but it's a change so noting it just in case.