- This topic has 8 replies, 4 voices, and was last updated 8 years, 1 month ago by
.
-
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
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
You must be logged in to reply to this topic.