Sound stop playing after a while

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Play something
2. Wait for a while

What is the expected output? What do you see instead?
Songs playing normally, then after 10/12 hours of flawless playback the sound 
stop working and a crackling sound starts popping every 10 seconds

What version of the product are you using? On what operating system?
version 1.0 
Linux multilite 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l 
GNU/Linux

Please provide any additional information below.

Original issue reported on code.google.com by digitala...@gmail.com on 14 Mar 2013 at 7:47

[GoogleCodeExporter]

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.

Original comment by trio...@btinternet.com on 14 Mar 2013 at 9:08

[GoogleCodeExporter]

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

Original comment by digitala...@gmail.com on 15 Mar 2013 at 7:11

[GoogleCodeExporter]

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?

Original comment by digitala...@gmail.com on 15 Mar 2013 at 8:17

[GoogleCodeExporter]

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. 

Original comment by trio...@btinternet.com on 15 Mar 2013 at 10:12

[GoogleCodeExporter]

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?

Original comment by digitala...@gmail.com on 15 Mar 2013 at 10:39

[GoogleCodeExporter]

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

Original comment by trio...@btinternet.com on 15 Mar 2013 at 10:45

[GoogleCodeExporter]

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

Original comment by digitala...@gmail.com on 15 Mar 2013 at 11:20

[GoogleCodeExporter]

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

Original comment by trio...@btinternet.com on 15 Mar 2013 at 1:11

• Changed state: Invalid

[GoogleCodeExporter]

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?

Original comment by cstre...@gmail.com on 26 Mar 2013 at 8:27

[GoogleCodeExporter]

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)

Original comment by trio...@btinternet.com on 26 Mar 2013 at 9:09

[GoogleCodeExporter]

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?

Original comment by ZQRST...@gmail.com on 1 Jan 2014 at 7:44