Stuttering or no sound on resume every morning or so… PCM2707 USB DAC

Max2Play Home Forums Max2Play on Raspberry PI Stuttering or no sound on resume every morning or so… PCM2707 USB DAC

Viewing 9 posts - 1 through 9 (of 9 total)
  • 20. Februar 2016 at 4:52 #18615

    Hi guys. I feel sorry to bother everyone with my problem, but I would highly appreciate some advice in order to pinpoint the origin of my problem.

    Here is the problem :

    I have built a couple of audio media players using Raspberry Pi 2 and Max2play.
    Max2play version is 2.27
    Debian Kernel version is 4.1.16-v7+
    Logitech Media Server version is 7.9.0 – 1455017172
    Squeezlite version is v1.8

    Everything works extremely well, the only issue I have, and it is quite annoying, is that every morning, when I resume playback after a pause of several hours, the player only plays back stuttering sound (sounds like a sample looping rapidly every 1/3 of a second roughly). This can also happen while I am playing a track or a stream. Sometimes it does not output any sound at all. The type of content (file, stream, FLAC or MP3) that I am playing does not make any difference. I have tried updating every software component on these appliances, but it does not make any difference.
    This behavior seems to occur randomly. It does not seem to be hardware related (no overheating, proven design for the DAC, PSU stable and clean).

    Important fact is that I have exactly the same issue on both media players that I have built.

    I have tried :
    Modifying launch parameters for squeezelite (see below for the launch parameters). I have varied the buffer parameters without any noticeable change, but I have noticed that removing completely the parameters seems to improve the stability (not even sure about this). But I may be wrong here and maybe there is a specific set of parameters the would improve the stability completely for my specific USB DAC.
    I have also tried the plugin trick inside LMS with Powersave v7.4 script.
    I have tried getting logs out of sqeezelite, but it does not show anything looking like an error even when the error occurs.
    When the playback fails, the squeezelite process seems frozen, but does not show up as such in my process lists. It appears as a normally behaving process. I can restart it using a python script (or manually), and it would restart normally, solving completely the issue. Sometimes, I get the new process playing back properly while the old process outputting stuttering sound keeps playing for a few seconds before dying off.
    The USB DACs I use are both home made, based on a Ti PCM2707 front chip (as seen by the computer), while the audio DAC itself is PCM1794 or Wolfson WM8524 using the I2S output of the PCM2707. These are highly proven designs that have been running perfectly for a couple of years on several PCs with all versions of Linux Mint, Ubuntu and Windows. I have never encountered this kind of issue in the past, even using ALSA, Pulseaudio, WASAPI or other sinks. So the USB DAC itself is out of the equation in my opinion. Also the DAC power supply is directly wired to a very good source outputting a perfectly regulated and filtered 5V (bypassing internal Raspeberry Pi internal VCC). So the power supply is not my main suspect here.

    After searching various forums for a while, seeing that squeezelite seems to behave normaly, I start to believe that there is an issue with the way ALSA is set up by default and that the instability is related to ALSA or the USB driver in Debian for my specific DAC. Which is weird as Linux Mint which is Debian based does not have this issue…

    Any idea on what could be wrong here causing this instability (squeezelite start parameters ?), or how I could get a valid log output to see what is happening ?
    Neither dmesg nor syslog seem to log anything wrong, I have checked regularly and cannot find anything interesting.

    Thanks for your help !!

    Here’s a lsusb output
    root@bedroom-player:/home/pi# lsusb
    Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
    Bus 001 Device 004: ID 08bb:2707 Texas Instruments Japan

    Here’s the /etc/modprobe.d/alsa-base.conf

    # autoloader aliases
    install sound-slot-0 /sbin/modprobe snd-card-0
    install sound-slot-1 /sbin/modprobe snd-card-1
    install sound-slot-2 /sbin/modprobe snd-card-2
    install sound-slot-3 /sbin/modprobe snd-card-3
    install sound-slot-4 /sbin/modprobe snd-card-4
    install sound-slot-5 /sbin/modprobe snd-card-5
    install sound-slot-6 /sbin/modprobe snd-card-6
    install sound-slot-7 /sbin/modprobe snd-card-7
    # Cause optional modules to be loaded above generic modules
    install snd /sbin/modprobe –ignore-install snd && { /sbin/modprobe –quiet snd-ioctl32 ; /sbin/modprobe –quiet snd-seq ; : ; }
    install snd-rawmidi /sbin/modprobe –ignore-install snd-rawmidi && { /sbin/modprobe –quiet snd-seq-midi ; : ; }
    install snd-emu10k1 /sbin/modprobe –ignore-install snd-emu10k1 && { /sbin/modprobe –quiet snd-emu10k1-synth ; : ; }
    # Keep snd-pcsp from beeing loaded as first soundcard
    options snd-pcsp index=-2
    # Keep snd-usb-audio from beeing loaded as first soundcard
    options snd-usb-audio index=-2
    # Prevent abnormal drivers from grabbing index 0
    options bt87x index=-2
    options cx88_alsa index=-2
    options snd-atiixp-modem index=-2
    options snd-intel8x0m index=-2
    options snd-via82xx-modem index=-2
    options snd-rpi-iqaudio-dac index=-2

    Here’s /home/pi/.asoundrc

    pcm.!default {
    type hw
    card 0

    ctl.!default {
    type hw
    card 0

    Here’s the squeezelite launch file

    ### Configuration of Audioplayers

    #### SQUEEZELITE -l ####
    Output devices:
    null – Discard all samples (playback) or generate zero samples (capture)
    plugequal – Equalizer for plughw:0,0
    default:CARD=ALSA – bcm2835 ALSA, bcm2835 ALSA – Default Audio Device
    sysdefault:CARD=ALSA – bcm2835 ALSA, bcm2835 ALSA – Default Audio Device
    default:CARD=DAC – USB Audio DAC, USB Audio – Default Audio Device
    sysdefault:CARD=DAC – USB Audio DAC, USB Audio – Default Audio Device
    front:CARD=DAC,DEV=0 – USB Audio DAC, USB Audio – Front speakers
    surround40:CARD=DAC,DEV=0 – USB Audio DAC, USB Audio – 4.0 Surround output to Front and Rear speakers
    surround41:CARD=DAC,DEV=0 – USB Audio DAC, USB Audio – 4.1 Surround output to Front, Rear and Subwoofer speakers
    surround50:CARD=DAC,DEV=0 – USB Audio DAC, USB Audio – 5.0 Surround output to Front, Center and Rear speakers
    surround51:CARD=DAC,DEV=0 – USB Audio DAC, USB Audio – 5.1 Surround output to Front, Center, Rear and Subwoofer speakers
    surround71:CARD=DAC,DEV=0 – USB Audio DAC, USB Audio – 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
    iec958:CARD=DAC,DEV=0 – USB Audio DAC, USB Audio – IEC958 (S/PDIF) Digital Audio Output




    20. Februar 2016 at 20:17 #18622

    Update on my issue. I have managed to log at sdebug level and forced the output to -o hw:1,0 and set the -a to 300:4:16::
    So far so good !

    First interesting thing, if I launch the squeezelite process using the default pi user, I get two errors with output_init_alsa. One for locking memory, one for setting output sched fifo rt. These errors do not occur if I launch squeezelite as root user. So there seems to be a problem in the user permissions for pi user locking memory and fifo rate when launching squeezelite with default settings. I have checked that the pi user is part of the audio user group.

    As a side note, it is also impossible to get logs outputs from squeezelite process to /var/log due to default pi user permissions (ok this is kinda normal, but frankly it is annoying…).

    IMHO These behaviors should be addressed at the distro level ! Also it would be quite useful to have a logging drop down list or toggle from within the web GUI, not a very difficult thing to do and extremely useful for everybody.

    Second point, I see that libmad is the main codec used (as it is the mp3 decoder by default). I managed to grab the following errors today which do not currently trigger the stuttering issue. Playback resumes normally by itself so far. I believe that these errors are related to the audio stream itself (web radio).

    [11:13:27.264582] mad_decode:230 mad_frame_decode error: lost synchronization
    [11:13:27.269263] mad_decode:230 mad_frame_decode error: forbidden bitrate value
    [11:13:27.269359] mad_decode:230 mad_frame_decode error: reserved sample frequency value
    [11:13:27.269446] mad_decode:230 mad_frame_decode error: lost synchronization
    [11:13:27.272419] mad_decode:230 mad_frame_decode error: bad main_data_begin pointer

    Overall I have found the following post, showing a very similar behavior, and related to libmad. If I still have errors, I will try to exclude the mad codec using the launch parameter -e mad

    • This reply was modified 8 years, 4 months ago by Lefuneste.
    29. Februar 2016 at 14:31 #18838

    Hi Lefuneste,
    You can set the hw parameter in our webinterface under the Advanced Settings of Squeezelite, which we would recommend since Max2Play is intended to be controlled over the web interface. Regarding the issues with your USB sound card, we can unfortunately not offer support for specific USB DAC’s since there has been such a vast output of them ranging immensely in quality. We would advise you to contact the manufacturer for support.
    For the best Max2Play result we would recommend using a freshly burnt image and setting the hardware parameter in the web interface.

    7. März 2016 at 20:19 #19163

    I have the same problem :
    my Dac is a Terratec Aureon Dual USB
    but he walks squeezlite classic that’s when I do not understand ,
    and especially never worries in airplay .

    J’ai le même probléme :
    mon Dac est un Terratec Aureon Dual USB
    mais il marche en squeezlite classic c’est là que je ne comprends pas,
    et surtout jamais de soucis en airplay.

    I rpi2 has 3 receptors , the server is a Synology DS audio for airplay and squeezserver
    I have two and a max2play squeezlite
    I encounter a trouble after several hours on both max2play only:
    I explain , I listen to music at night and the next day
    morning I want to revive squeezlite max2play and there, as the sound is blocked even if I change track while if I run sound airplay
    it works very well .
    If I restart the electrically raspberry rpi2 it well until remarche a long time
    not in use , but no problem with the original squeezlite .

    Can you tell me what to do ? because I ‚m not a pro but if you give me a step by step process I follow
    I use putty and winscp

    thanks in advance

    Je posséde 3 rpi2 recepteurs, le serveur est un synology ds audio pour airplay et squeezserver
    j’ai deux max2play et un squeezlite
    je rencontre un soucis apres plusieurs heures sur les deux max2play uniquement :
    je m’explique, j’ecoute la musique le soir et le lendemain
    matin je veux relancer les squeezlite max2play et là, le son est comme bloqué même si je change de piste alors que si je lance un son airplay
    cela fonctionne trés bien.
    si je redémarre electriquement le raspberry rpi2 cela remarche bien jusqu’à a un long moment
    de non utilisation mais aucun probléme avec le squeezlite d’origine.

    Pouvez-vous me dire quoi faire ? car je ne suis pas un pro mais si on me donne une démarche pas à pas je peux la suivre
    j’utilise winscp et putty

    merci par avance

    7. März 2016 at 21:22 #19164

    Hello Christophe;

    I have successfully resolved this issue. For information I build my own DACs (USB sound cards if you will), and the front receiver chip is a TI PCM2707. It is widely used on many entry levels and mid-level USB sound cards, and it is what is seen and registered by the Raspberry Pi as a USB device (type command line „lsusb“ to check what chip is seen by your OS). But it doesn’t matter that much after all…

    So the trick seems to be to force squeezelite to use hardware address of the device instead of the alias provided by ALSA. For some reason the instability seems more or less related to ALSA losing the link to the hardware. When using a hardware address in squeezelite instead of the symbolic address, the connection to the sound device seems rock solid. According to some other posts I’ve seen (link in my previous post), it may also be related to the fact that logging is enabled in my startup command. Apparently if no logging is specified, squeezelite could be more prone to stability issues. I haven’t crossed tested this element, but I prefer to have logging enabled anyway.

    So the key is to edit the startup file for squeezelite by typing : nano /opt/max2play/audioplayer.conf

    Here’s mine :

    ### Configuration of Audioplayers
    SQUEEZELITE_PARAMETER=-o hw:1,0 -a 300:4:16: -v -d all=debug -f /var/log/squeezelite.log

    You will notice that in this file you specify the startup command options for squeezelite : -o hw:1,0 -a 300:4:16: -v -d all=debug -f /var/log/squeezelite.log

    Also I specify USE_USB_DAC=1 which is not absolutely necessary I believe.

    Beware that if you modify anything in the Max2play web interface (advanced settings) afterwards, you will replace the startup parameters for the sound card and will have to re-modify them by hand. Max2play does not control that you have specified some parameters and writes them off automatically to replace the -o parameter with the symbolic address of the card.

    The -o is for the output device
    The -a is for the audio data format and buffer size to send to the DAC
    The -V is for enabling visulization handles in Jivelite so it is optional if you don’t use a screen
    The -d is for the logging level. I started with all=sdebug to pinpoint errors (it generated 300 Mb files per day) then switched to all=debug which is good enough and generates about 3 Mb per day on par with syslog). Keep in mind that you want to minimize this as it will age your sd card if you write too much.
    The -f is the output of the log file. You will notice that by default the squeezelite process is launched using pi user (parameter SYSTEM_USER=pi). This is good and bad… Good as it is the best practice to have a dedicated user for a process, but by default the pi user is unable to write into /var/log. So I enabled the write permissions for the „root“ group on the /var/log directory (chmod -R 775 /var/log/) and added the „root“ group to the user pi. You can also decide to output your log file in a place where pi user is able to write.

    Another bigger problem with the pi user is that it gives two errors when launching the audio interface. They do not happen is you specify the user „root“ in this startup script, but then you end up having problems with the display interface of Max2play. The RPI Display page is not correctly working anymore, apparently detecting another hardware device (some stupid message that it is only available for Odroid), and Jivelite is unable to restart also invoking odroid user or something funny. No idea why there is this crossed side effect…

    For more options the best resource for squeezelite startup parameters I’ve found is :

    Beware that I am not setting up airshare at squeezelite level !! So you will have to adapt your startup file accordingly !

    Hope this will help

    • This reply was modified 8 years, 3 months ago by Lefuneste.
    7. März 2016 at 21:26 #19166

    Thanks Heiner. Setting up squeezelite to use hardware address solved the issue. As for the manufacturer of the sound card (myself), I can confirm it is now working 😉

    8. März 2016 at 10:19 #19168


    I have the same problem with Sound Science QSB USB speakers, stuttering or no sound after few hours …
    I will try the hw:1,0 parametter

    10. März 2016 at 2:06 #19182

    Hello Omega,

    Using hw:1,0 seemed to do the trick for me. As stated above, keep in mind that any further modification in the web GUI on Advanced parameters for squeezelite will force the -o parameter to something else (taken from the drop down list of available soundcards provided by ALSA as I believe).

    10. März 2016 at 18:48 #19201

    Using hw:1,0 is ok for me also 🙂

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

Register here