Sound stop playing after a while about squeezelite HOT 11 CLOSED

What's the hardware?  Is it reproducable multiple times after 10 to 12 hours?  
If so could you enable debugging and see what happens after this time.  Best to 
enable "-d output=debug" to get debugging related to the audio output.

Also are you running as root or with a user which is allowed to run real time 
priorites?  This should definately help on a PREMPT kernel.

The hardware is a raspberry Pi Model B with the lastest raspbian OS.
i'm currently running the armhf version... And for the bug, i'm just waiting 
for it to do it again (i've enabled the debug output just in case of that...)

ps: i'm running it as root user

I've found the problem.

The "glitch" occurs while the system try to reproduce any other sound using the 
same output device that squeezelite is using.

root@multilite:~# squeezelite -d output=debug 10.0.0.11
[09:06:46.397804] output_init:1298 init output
[09:06:46.399968] output_init:1301 outputbuf size: 3528000
[09:06:46.401232] output_init:1333 requested buffer_time: 20000 period_count: 4 
format: any mmap: 1
[09:06:46.420162] output_init:1357 output: default maxrate: 384000
[09:06:46.435108] output_init:1367 memory locked
[09:06:46.437183] output_thread:576 open output device: default
[09:06:46.439956] output_init:1390 set output sched fifo rt: 45
[09:06:46.449146] alsa_open:262 opened device default using format: S32_LE 
sample rate: 44100 mmap: 1
[09:06:46.450553] alsa_open:310 buffer time: 23219 period count: 4 buffer size: 
1024 period size: 256
[09:06:46.488903] output_flush:1402 flush output buffer
[09:06:47.567363] output_thread:766 track start sample rate: 44100 replay_gain: 
0
***** HERE I TRY TO REPRODUCE A SOUND USING THE COMMAND "mpg123 play.mp3" 
****************
*** play.mp3 is playing on top of the squeezelite sound ********
*** when the play.mp3 is over, audio starts to glitch, and the squeezelite log 
says *****
[09:07:54.013955] output_thread:698 skip 441 of 441 frames




i cant stop squeezelite using ^C or any other method (kill, killall, kill 
-9...), the process remains there and says:
[09:08:24.098180] output_close:1416 close output 
but i cant do anything (the bash shell dont respawn and the audio output is 
never released, so i have to unplug and replug my raspberry to have it running 
again)


Is there a way to lock out the audio output while squeezelite is running? Or 
maybe using another driver instead of alsa?

Looks like you are using sync - thats what causes the "skik 441 of 441 frames" 
message.  I suspect what is happening is that the system sounds are causing the 
clock frequency to change and this means sync needs to skip to stay in sync.

Suggest using "-o hw:CARD=<card name>" to get exclusive access to the output 
device or not using sync if you need to share the output device. 

Trying right now... but how i can ge the right card name? I'm using "ALSA" as 
card name... is there any useful command to get the name?

I think it is ALSA on the pi, squeezelite -l should give a list

started it with "ALSA" as sound card's name, but the problem still persists.. 
when i then use "aplay" i correctly hear the demo mp3 and then the sound output 
is muted, or out of sync and sounds like a car accident comes from it...


Just shooting a thing: what if i try to use pulseaudio to reroute the sound on 
it? I heard that pulseaudio can lock the sound card from being used by other 
applications

Sorry don't know - will close this as its a PI not Squeezelite issue - suggest 
you discuss on the forums to see if others can help

I get the exact same behavior as reported in this issue, but I also think it is 
a hardware issue, because I have an other RPi that does not have this problem.

Have anyone found a way to fix this issue?

If this problem is specific to running the players sychronised, then it will 
depend how accurate the playback frequency of each device - skips occur 
whenever the playback frequency differs.  In the case of having a software 
mixer which resamples to another rate (which sounds like it is the original 
case this is likely to make the problem worse).  Squeezelite can't work around 
these cases, so sync should be considered a feature which will work best when 
there minimal variations between hardware and when the playback crystal is 
known to be close to the absolute frequency (as with hardware SB players)

I have run into the same problem but found that issuing the following command 
restarts squeezelite:

sudo /etc/init.d/squeezelite force-reload

I do not know how to use it to recover automatically. Any ideas?