- This topic has 5 replies, 1 voice, and was last updated 8 years, 7 months ago by
.
-
Hi guys. So I’ve spent the entire day trying to figure out what my problem is with 2.29 on Pi3. Something is definitely going very wrong but I believe it is a side effect of new packages brought by apt-get upgrades delivered since your release date.
I was previously working with a Pi3 on Raspian Jessie (Full) with ad-hoc max2play github install. The system managed to be quite stable after a couple of weeks of fine tuning. Suddenly this morning everything went bezerk. The squeezelite process began to restart every minute. I first thought about a problem with a cron task. After 3 hours messing around, nothing could change the behaviour. I reinstalled all apps LMS, Squeezelite, Jivelite and so on… Nothing… So I decided to move to your latest official release thinking that I may have encountered a side effect of my custom install. After flashing the new version, I discovered a series of very annoying issues :-Reboot is not smooth at all.
First issue, out of the box, I get stopped by sticky processes on every reboot forcing me to hard reset. I thought this was due to some IPV6 dibbler nuisance, but no. Of course I have not been able to pin point the origin of this behavior sometimes it hangs on Apache, Samba or others… I often get this message : „a stop job is running for session of user pi“ forcing me to wait for 1:30 before resuming the shutdown-Not a 100% sure this was brought by apt-get updates / upgrades but it seems like it as after fresh install I didn’t notice such a behavior
I get the following at boot (parsed from dmesg log) once the system is upgraded. I haven’t been able to solve this yet[ 4.699837] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
[ 4.734590] systemd[1]: Found ordering cycle on basic.target/start
[ 4.749255] systemd[1]: Found dependency on sysinit.target/start
[ 4.763574] systemd[1]: Found dependency on raspi-config.service/start
[ 4.778883] systemd[1]: Found dependency on remote-fs.target/start
[ 4.793460] systemd[1]: Found dependency on media-musique.mount/start
[ 4.808527] systemd[1]: Found dependency on network.target/start
[ 4.822731] systemd[1]: Found dependency on dhcpcd.service/start
[ 4.836889] systemd[1]: Found dependency on basic.target/start
[ 4.850682] systemd[1]: Breaking ordering cycle by deleting job raspi-config.service/start
[ 4.869420] systemd[1]: Job raspi-config.service/start deleted to break ordering cycle starting with basic.target/start
[ 4.897821] systemd[1]: Found ordering cycle on basic.target/start
[ 4.912403] systemd[1]: Found dependency on sysinit.target/start
[ 4.926632] systemd[1]: Found dependency on console-setup.service/start
[ 4.942061] systemd[1]: Found dependency on remote-fs.target/start
[ 4.956598] systemd[1]: Found dependency on media-musique.mount/start
[ 4.971632] systemd[1]: Found dependency on network.target/start
[ 4.985768] systemd[1]: Found dependency on dhcpcd.service/start
[ 4.999852] systemd[1]: Found dependency on basic.target/start
[ 5.013487] systemd[1]: Breaking ordering cycle by deleting job console-setup.service/start
[ 5.032237] systemd[1]: Job console-setup.service/start deleted to break ordering cycle starting with basic.target/start
[ 5.059947] systemd[1]: Found ordering cycle on basic.target/start
[ 5.074217] systemd[1]: Found dependency on sysinit.target/start
[ 5.088124] systemd[1]: Found dependency on kbd.service/start
[ 5.101494] systemd[1]: Found dependency on remote-fs.target/start
[ 5.115743] systemd[1]: Found dependency on media-musique.mount/start
[ 5.130529] systemd[1]: Found dependency on network.target/start
[ 5.144424] systemd[1]: Found dependency on dhcpcd.service/start
[ 5.158313] systemd[1]: Found dependency on basic.target/start
[ 5.171854] systemd[1]: Breaking ordering cycle by deleting job kbd.service/start
[ 5.188761] systemd[1]: Job kbd.service/start deleted to break ordering cycle starting with basic.target/startThen a couple seconds later :
[ 6.117014] systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
[ 6.146285] systemd[1]: Failed to start Load Kernel Modules.This looks very bad !!! And I got to this exact same errors after 2 reinstalls from scratch !! I think one package update is destroying the distro…
-Now the most annoying of all by far. I had managed to completely stabilize my Rpi 2 on M2P/Wheezy and my USB DAC using -o hw:1,0 for the start parameters of squeezelite (see my other posts). Now with 2.29, although the same parameters do apply indeed (another 2 hours testing ALL POSSIBLE -o parameters), I get the USB DAC working, but there is a problem in the sound. It randomly „spits“ or „stutter“ every 10 to 20 seconds roughly. It seems very random and extremly annoying, and linked to some form of interruption going on on the USB link. I am using the internal wifi adapter so it may be the culprit… The sound module declared in /etc/module is snd_usb_hiface. It seems to have HUGE issues with Jessie and the Rpi3 according to some squeezelite logs I’ve got (hw busy, unable to address the hardware, I/O erros and so on)… I’ve had to mess round and reinstall 2.29 from scratch twice to get any sound at all. I never had such an issue before on Rpi2 on previous versions. Only long term (1 day or so) stability issues on resume (alsa problem most likely), but never sound quality problems. Currently CPU is very low, as well as Mem usage. Nothing is going on. -d all=sdebug shows some sort of time discrepancy between the Rpi3 and the USB card which may be the origin of the „lost sampled“ sounds appearing randomly. It feels like the origin of the problem is internal to the Rpi3.
I get this sort of log, no idea if this is normal :[22:54:22.061142] stream_thread:270 streambuf read 3762 bytes
[22:54:22.261546] stream_thread:270 streambuf read 3761 bytes
[22:54:22.361863] stream_thread:270 streambuf read 3762 bytes
[22:54:22.562237] stream_thread:270 streambuf read 3721 bytes
[22:54:22.662490] stream_thread:270 streambuf read 1 bytes
[22:54:22.662624] stream_thread:270 streambuf read 3801 bytes
[22:54:22.762839] stream_thread:270 streambuf read 3762 bytes
[22:54:22.963205] stream_thread:270 streambuf read 3761 bytes
[22:54:23.063491] stream_thread:270 streambuf read 3762 bytes
[22:54:23.263863] stream_thread:270 streambuf read 3762 bytesOr
[22:58:36.338132] stream_thread:270 streambuf read 32768 bytes
[22:58:36.339199] stream_thread:270 streambuf read 32768 bytes
[22:58:36.340253] stream_thread:270 streambuf read 32768 bytes
[22:58:36.341262] stream_thread:270 streambuf read 32768 bytes
[22:58:36.342245] stream_thread:270 streambuf read 32768 bytes
[22:58:36.442508] stream_thread:278 poll timeout
[22:58:36.542848] stream_thread:278 poll timeout
[22:58:36.596577] stream_thread:270 streambuf read 32768 bytes
[22:58:36.597602] stream_thread:270 streambuf read 32768 bytes
[22:58:36.598619] stream_thread:270 streambuf read 32768 bytes
[22:58:36.599701] stream_thread:270 streambuf read 32768 bytes
[22:58:36.600916] stream_thread:270 streambuf read 32768 bytesBut frankly any sort of info on Alsa/Squeezelite error logs is one of the most difficult googling I’ve experienced. Maybe a higher priority process is taking some CPU interrupts, but how can this be on a 4 cores CPU… I tried to push squeezelite to -p 90 priority no change at all. Disabling logging did not change anything, neither fiddling with all documented parameters of squeezelite (buffers sampling and so on). The USB card is rock solid on my other PC and I know it well as I’m the manufacturer of this DAC.
Anyway I’ll try to google some more on the failed modules load which is pretty scary…
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.
You must be logged in to reply to this topic.