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:plugequal
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
