opened
thebigtouffe
username_0
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;
```
Audio stuttering after long inactivity using ALSA dmix
issue
created
willstott101
username_1
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.
comment
created
willstott101
username_1
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
comment
created
kingosticks
username_2
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?
comment
created
thebigtouffe
username_0
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.
comment
created
thebigtouffe
username_0
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`.
comment
created
kingosticks
username_2
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. 

The cpu scaling govenator is controlled through the /sys filesystem (https://raspberrypi.stackexchange.com/questions/9034/how-to-change-the-default-governor#9048). It's not about overclocking, it's about preventing underclocking. However, if this is specific to dmix then maybe it'll make no difference.
comment
created
thebigtouffe
username_0
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.
comment
closed
thebigtouffe
username_0
issue