[GH-ISSUE #329] Audio stuttering after long inactivity using ALSA dmix #214

Closed
opened 2026-02-27 19:29:27 +03:00 by kerem · 7 comments
Owner

Originally created by @thebigtouffe on GitHub (Apr 13, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/329

Hello guys,

My audio is stuttering after several hours of inactivity (ie no tracks played). I play music on a custom alsa device that uses dmix module. I tried to increase the buffer size in ALSA conf, but it has no effect whatsoever (and testing does require patience). A workaround is to periodically restart librespot. Though I do not think this is a bug in librespot I wanted to document this issue. I will run librespot in verbose mode to get more information.

I am running Mar 27, 2019 version compiled on a Raspberry Pi 2 using HifiBerry DAC+.

Here is my ALSA config:

pcm.ossmix {
    type dmix
    ipc_key 1024 # must be unique!
    ipc_key_add_uid false   # let multiple users share
    ipc_perm 0666           # IPC permissions for multi-user sharing (octal, de$
    slave {
        pcm "hw:0,0"      # you cannot use a "plug" device here, darn.
        period_time 0
        period_size 1024 # must be power of 2
        buffer_size 16384  # dito. It
        rate 44100
       #format "S32_LE"
       #periods 128 # dito.
       #rate 8000 # with rate 8000 you *will* hear,
       # if ossmix is used :)
    }
    # bindings are cool. This says, that only the first
    # two channels are to be used by dmix, which is
    # enough for (most) oss apps and also lets
    # multichannel chios work much faster:
    bindings {
        0 0 # from 0 => to 0
        1 1 # from 1 => to 1
    }
}
pcm.dsp0 {
    type plug
    slave.pcm "ossmix" # use our new PCM here
}
# mixer0 like above
ctl.mixer0 {
    type hw
    card 0
}

# You may want to make your new ossmix the default for alsa.
# If your alsa programs are complaining that they can't open
# your sound devices, try uncommenting this next line
pcm.default pcm.dsp0

The command I use to run librespot : /usr/bin/librespot --name XXX --bitrate 160 --username YYY --password ZZZ --disable-audio-cache --device ossmix --enable-volume-normalisation

Since I use raspotify for daemonizing I run the following script every hour to avoid audio stuttering:

#!/bin/bash
last_track_date=$(service raspotify status|grep Track|tail -n 1|grep -Eo ".* <host>"|sed 's/ <host>//')
last_track_ts=$(date -d "$last_track_date" +%s)

echo $last_track_ts

delta=$(( $(date +%s) - $last_track_ts ))
if [[ $delta -lt 600 ]]; then
        echo "Not restarting";
else
        echo "Restarting"
        service raspotify restart
fi;
Originally created by @thebigtouffe on GitHub (Apr 13, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/329 Hello guys, My audio is stuttering after several hours of inactivity (ie no tracks played). I play music on a custom alsa device that uses dmix module. I tried to increase the buffer size in ALSA conf, but it has no effect whatsoever (and testing does require patience). A workaround is to periodically restart librespot. Though I do not think this is a bug in librespot I wanted to document this issue. I will run librespot in verbose mode to get more information. I am running Mar 27, 2019 version compiled on a Raspberry Pi 2 using HifiBerry DAC+. Here is my ALSA config: ``` pcm.ossmix { type dmix ipc_key 1024 # must be unique! ipc_key_add_uid false # let multiple users share ipc_perm 0666 # IPC permissions for multi-user sharing (octal, de$ slave { pcm "hw:0,0" # you cannot use a "plug" device here, darn. period_time 0 period_size 1024 # must be power of 2 buffer_size 16384 # dito. It rate 44100 #format "S32_LE" #periods 128 # dito. #rate 8000 # with rate 8000 you *will* hear, # if ossmix is used :) } # bindings are cool. This says, that only the first # two channels are to be used by dmix, which is # enough for (most) oss apps and also lets # multichannel chios work much faster: bindings { 0 0 # from 0 => to 0 1 1 # from 1 => to 1 } } pcm.dsp0 { type plug slave.pcm "ossmix" # use our new PCM here } # mixer0 like above ctl.mixer0 { type hw card 0 } # You may want to make your new ossmix the default for alsa. # If your alsa programs are complaining that they can't open # your sound devices, try uncommenting this next line pcm.default pcm.dsp0 ``` The command I use to run librespot : `/usr/bin/librespot --name XXX --bitrate 160 --username YYY --password ZZZ --disable-audio-cache --device ossmix --enable-volume-normalisation` Since I use raspotify for daemonizing I run the following script every hour to avoid audio stuttering: ``` #!/bin/bash last_track_date=$(service raspotify status|grep Track|tail -n 1|grep -Eo ".* <host>"|sed 's/ <host>//') last_track_ts=$(date -d "$last_track_date" +%s) echo $last_track_ts delta=$(( $(date +%s) - $last_track_ts )) if [[ $delta -lt 600 ]]; then echo "Not restarting"; else echo "Restarting" service raspotify restart fi; ```
kerem closed this issue 2026-02-27 19:29:27 +03:00
Author
Owner

@willstott101 commented on GitHub (Apr 13, 2019):

Are you using the current master (Rodio backend) or a slightly older version (portaudio)?

The version of the Rodio backend in master doesn't release the audio device when it stops playing. Maybe try using the alsa backend directly.

Build with --features alsa-backend and run with --backend alsa but everything else the same.

<!-- gh-comment-id:482787768 --> @willstott101 commented on GitHub (Apr 13, 2019): Are you using the current master (Rodio backend) or a slightly older version (portaudio)? The version of the Rodio backend in master doesn't release the audio device when it stops playing. Maybe try using the alsa backend directly. Build with `--features alsa-backend` and run with `--backend alsa` but everything else the same.
Author
Owner

@willstott101 commented on GitHub (Apr 13, 2019):

I wasn't sure if this would ever cause issues but this sounds exactly like it might be a symptom. I have a PR to help resolve this, but I'm waiting on upstream Rodio to iron out a few issues

<!-- gh-comment-id:482788108 --> @willstott101 commented on GitHub (Apr 13, 2019): I wasn't sure if this would ever cause issues but this sounds exactly like it might be a symptom. I have a PR to help resolve this, but I'm waiting on upstream Rodio to iron out a few issues
Author
Owner

@kingosticks commented on GitHub (Apr 13, 2019):

This is raspotify on a pi, which is built with only the alsa backend.

I guess the question I have is, does the stuttering stop if it's left playing for a while or if you skip tracks? Have you tried without the dmix plug? Have you tried disabling the dynamic cpu scaling governor that raspbian uses by default?

<!-- gh-comment-id:482798330 --> @kingosticks commented on GitHub (Apr 13, 2019): This is raspotify on a pi, which is built with only the alsa backend. I guess the question I have is, does the stuttering stop if it's left playing for a while or if you skip tracks? Have you tried without the dmix plug? Have you tried disabling the dynamic cpu scaling governor that raspbian uses by default?
Author
Owner

@thebigtouffe commented on GitHub (Apr 14, 2019):

Are you using the current master (Rodio backend) or a slightly older version (portaudio)?

The version of the Rodio backend in master doesn't release the audio device when it stops playing. Maybe try using the alsa backend directly.

Build with --features alsa-backend and run with --backend alsa but everything else the same.

I am using Rodio sink. I will try with ALSA backend directly and with latest version. Audio was stuttering this morning, but I found nothing particular in librespot logs.

<!-- gh-comment-id:482929860 --> @thebigtouffe commented on GitHub (Apr 14, 2019): > Are you using the current master (Rodio backend) or a slightly older version (portaudio)? > > The version of the Rodio backend in master doesn't release the audio device when it stops playing. Maybe try using the alsa backend directly. > > Build with `--features alsa-backend` and run with `--backend alsa` but everything else the same. I am using Rodio sink. I will try with ALSA backend directly and with latest version. Audio was stuttering this morning, but I found nothing particular in librespot logs.
Author
Owner

@thebigtouffe commented on GitHub (Apr 14, 2019):

This is raspotify on a pi, which is built with only the alsa backend.

I guess the question I have is, does the stuttering stop if it's left playing for a while or if you skip tracks? Have you tried without the dmix plug? Have you tried disabling the dynamic cpu scaling governor that raspbian uses by default?

I only use raspotify for daemonizing, I compile librespot myself. The audio is still stuttering after at least a minute (didn't try longer than that) and changing track doesn't help.

Without dmix I did not have this problem, but librespot often crashed because many apps had access to the default ALSA device (which allows only one source). Besides, I was using an old version that did not feature rodio if I remember correctly.

I don't use Raspbian but osmc, but I think both have force_turbo=0. I will try with force_turbo=1.

<!-- gh-comment-id:482931877 --> @thebigtouffe commented on GitHub (Apr 14, 2019): > This is raspotify on a pi, which is built with only the alsa backend. > > I guess the question I have is, does the stuttering stop if it's left playing for a while or if you skip tracks? Have you tried without the dmix plug? Have you tried disabling the dynamic cpu scaling governor that raspbian uses by default? I only use raspotify for daemonizing, I compile librespot myself. The audio is still stuttering after at least a minute (didn't try longer than that) and changing track doesn't help. Without dmix I did not have this problem, but librespot often crashed because many apps had access to the default ALSA device (which allows only one source). Besides, I was using an old version that did not feature rodio if I remember correctly. I don't use Raspbian but osmc, but I think both have `force_turbo=0`. I will try with `force_turbo=1`.
Author
Owner

@kingosticks commented on GitHub (Apr 14, 2019):

Ahh, sorry, my misunderstand. Maybe it is related to rodio issue. but since that dmix config is specifically for supporting the case where the device isn't released it doesn't make total sense yet.

Edit: The cpu scaling govenator can also be controlled through the /sys filesystem (https://raspberrypi.stackexchange.com/questions/9034/how-to-change-the-default-governor#9048) and that's how I've always done it. However, if this is specific to dmix then maybe it'll make no difference.

<!-- gh-comment-id:482980230 --> @kingosticks commented on GitHub (Apr 14, 2019): Ahh, sorry, my misunderstand. Maybe it is related to rodio issue. but since that dmix config is specifically for supporting the case where the device isn't released it doesn't make total sense yet. Edit: The cpu scaling govenator can also be controlled through the /sys filesystem (https://raspberrypi.stackexchange.com/questions/9034/how-to-change-the-default-governor#9048) and that's how I've always done it. However, if this is specific to dmix then maybe it'll make no difference.
Author
Owner

@thebigtouffe commented on GitHub (Apr 15, 2019):

Apparently it is related to rodio. I compiled latest version with alsa-backend feature and I did not get any stuttering using ALSA backend option after 8 hours of inactivity. I will keep on running librespot for a couple days to check if the stuttering reappears.

<!-- gh-comment-id:483388771 --> @thebigtouffe commented on GitHub (Apr 15, 2019): Apparently it is related to rodio. I compiled latest version with `alsa-backend` feature and I did not get any stuttering using ALSA backend option after 8 hours of inactivity. I will keep on running librespot for a couple days to check if the stuttering reappears.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#214
No description provided.