Forum Replies Created
-
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=-2I 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.
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
SQUEEZESLAVE_PARAMETER=-n plugequal
SHAIRPORT_PARAMETER=-d default:CARD=ALSA
USE_USB_DAC=1
USE_EQUALIZER=0
SYSTEM_USER=pi
GMEDIARENDER_ALSA_DEVICE=plug:plugequalYou 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
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 pointerOverall 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
https://github.com/DigitalDreamtimeLtd/squeezelite/issues/52
