Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • 10. April 2016 at 14:11 #19735

    I was about to give up and start again from scratch as I got stuttering sound whatever parameter I modified. Then I tried to edit /boot/config.txt to check if I had any hidden parameter.
    I saw this at the end of the file


    I tried to comment this line to see if it had any effect of loading a different kernel, and if loading a different kernel would have any effect.

    # kernel=kernel-m2p-4.1.13-v7+.img

    Also I had commented the snd_usb_hiface module out of /etc/modules so loading a standard kernel would not shout at me for missing module.

    # snd_usb_hiface

    And after reboot SUCCESS stuttering is GONE FOR GOOD even when using wifi access !!
    So I don’t know what is wrong within the kernel provided by M2P, but network access definitely screws up the sound on USB DAC with Rpi3.

    Overall I am quite relieved to have nailed this issue and I can now do updates and upgrades…

    10. April 2016 at 13:40 #19734

    I reinstalled M2P 2.29 fresh and kept it from any apt update or upgrade
    -Audio was rock solid out of the box
    Then did an apt update which installed 97 packets including Samba
    -Audio still perfect on LAN connection
    Then activated WiFi (internal Rpi3 WiFi)
    -Audio starting stuttering like crazy
    Moved back to wired LAN
    -Audio kept stuttering
    Tried to disable WiFi, blacklist WiFi related modules, stopped Samba, modified cmdline.txt file…
    -Audio still stuttering
    I have also tried to modify the mount options, currently using NFS shares from my NAS. No change whatsoever.

    It seems that activating the internal WiFi has screwed the audio quality in a non-reversible way. Will need to start again from scratch

    6. April 2016 at 14:13 #19659

    So after blacklisting and manually loading modules I confirm that there is an issue with the sound.
    The snd_audio_usb is the module that is working with my USB DAC, and only this module works. But contrary to the previous version on Wheezy kernel, I can notice a very clear degradation in sound quality. I believe that there is some sort of resource cross contamination with another device on the USB bus. Likely the WiFi module. I have tried unloading the WiFi module and will need some further tests.
    I have also noticed that in many cases, although I get the snd_usb_audio module to load properly and address the good device (the USB DAC) on squeezelite startup, I get no sound output. Logs show that the device is prperlly initialized, that the audio stream is properly processed, but I get no sound. To solve this I had to load the kernel without any sound module (blacklisting bcm2835, hiface and usb_audio ones) then load manually only snd_usb_audio by modprobe, in order to restore the sound output. This is quite weird. There seems to be an issue with the order in which modules are loaded, one other module restricting or grabbing the sound output.
    I have also noticed that on the new distribution, the /etc/modprobe.d/alsa-base.conf has only one line, whereas on the previous version based on wheezy I had many lines.

    New version

    options snd-rpi-iqaudio-dac index=-2

    Old version

    # 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

    I will start again using a fresh image to check more precisely what is happening (and avoid upgrading the kernel silly me!).

    The good thing is that I get to learn a lot on Linux base behavior 😉 This is all very interesting… And I’ve also ordered some I2S sound cards as it’s true that USB is not the best way to utilize the Rpi for sound.

    • This reply was modified 7 years, 8 months ago by Lefuneste.
    5. April 2016 at 17:08 #19643

    Ok problem was identified about the module. It is a non existing module in the kernel update Duhhhh… Nice guys at max2play have compiled the module inside their kernel… So upgrading the kernel is a no go…

    5. April 2016 at 9:52 #19619

    More investigations on this, now everything comes clearer 😉

    $ systemd-modules-load.service – Load Kernel Modules
    Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
    Active: failed (Result: exit-code) since mar. 2016-04-05 08:54:55 CEST; 55min ago
    Docs: man:systemd-modules-load.service(8)
    Process: 79 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
    Main PID: 79 (code=exited, status=1/FAILURE)

    $ sudo journalctl -b _PID=79
    — Logs begin at mar. 2016-04-05 08:54:55 CEST, end at mar. 2016-04-05 09:51:51 CEST. —
    avril 05 08:54:55 cave-player2 systemd-modules-load[79]: Inserted module ‚fuse‘
    avril 05 08:54:55 cave-player2 systemd-modules-load[79]: Failed to find module ’snd_usb_hiface‘

    So the module required for the USB DAC is not loaded properly… Bummer !!

    13. März 2016 at 22:58 #19241

    Ok I’ve tested another route.
    I’ve installed a fresh Raspian Jessie complete, expanded the FS from command line, and then ran the max2play install script from GitHub.
    Apart from a few quirks due to the fact that the install script must be moved one directory up, and the unzip directory must be renamed to max2play, it ran completely. It just misses the install of ffmpeg which is not available from standard repo and it tries to install hd-idle_1.05_armhf.deb which should be inside the git package but is not.
    After all this, I get exactly the same stupid mounts from mtab/fstab so I believe it is related to Jessie.
    Still the expand script does not work out of the box in the Beta version so something must be done.

    12. März 2016 at 0:49 #19221

    I haven’t tested the Jessie Beta on Rpi2 yet. I will try to reproduce it on Rpi2.

    After some intensive research it seems that :
    The mtab content found above is more or less normal.
    It should however release the temporary binds created at startup, in particular the one to the root file system.
    The problem seems thus related to the OS, in particular to the init scripts which create, then release the temporary mounts. I should end up with a unique mount to the root file system after boot, which is NOT the case. This may explain why the expansion script does not proceed successfully. Unfortunately my current knowledge of the init procedure stops me from correcting this issue.

    Let’s hope that new releases will be more polished. This is only a Beta…

    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).

    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 😉

    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 : http://manpages.ubuntu.com/manpages/trusty/man1/squeezelite.1.html

    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 7 years, 9 months ago by Lefuneste.
    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 7 years, 9 months ago by Lefuneste.
Viewing 11 posts - 1 through 11 (of 11 total)