play after long silcence produces garbage about squeezelite

[GoogleCodeExporter]

I have the same problème.
I use squeezelite 1.1 on a kirkwood based NAS (armV5) (Lacie D2 Network) and 
Debian 7.0.

But the probleme does not appears in a previous install of my systeme. I will 
do some test on a other machine whith the same CPU.

Original comment by [email protected] on 19 Jun 2013 at 5:56

[GoogleCodeExporter]

Are there any debug messages in the case of the garbage noise?

Original comment by [email protected] on 23 Jun 2013 at 5:06

[GoogleCodeExporter]

i see the same issue on my raspberry model B rev 1.0 running with a behringer 
uca202 as output device. 
This is my setup
relaible power supply -> raspberry pi -> powered USB hub (hub has wifi dongle 
and uca202 connected)
when started, i have used it for upto 3 hours without any issue. But when 
trying to use after the process has been running for about 20 to 24 hours, 
there is no sound output from the uca202. 

i run the process as follows
/home/pi/logitech/squeezelite-armv6hf -s 192.168.1.10 -o default:CARD=CODEC -n 
raspi -z 

i am now running with debugging enabled as follows
/home/pi/logitech/squeezelite-armv6hf -s 192.168.1.10 -o default:CARD=CODEC -n 
raspi -z -d all debug -f /home/pi/logitech/output.log

will upload the logs along with output of top when i run into the issue again. 

Original comment by [email protected] on 16 Jul 2013 at 7:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This one was rather intersting.
In the morning I turned squeezelite off by software.
Then I started playing a SomaFM stream. Out came garbage.
While I copied the log, The garbage transformed to the normal SomaFM stream....

strange...

Original comment by [email protected] on 27 Jul 2013 at 5:04

Attachments:

• squeezelite.log

[GoogleCodeExporter]

I have the same problem on Popoplug Mobile + Debian + Squeezelite v. 1.2. As 
well as wr703n + OpenWrt AA + Squeezelite v. 1.2.

Original comment by [email protected] on 8 Sep 2013 at 5:08

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have also issue 2 on wr703n. Can you also offer OSS Squeelite version? MPD 
and mplayer using OSS on my Dockstar works fine for years. Also ALSA lib is 
800Kb which is too big on 4Mb flash.

Original comment by [email protected] on 8 Sep 2013 at 5:21

[GoogleCodeExporter]

The library installed are libmpg123 and libFlac.

Original comment by [email protected] on 8 Sep 2013 at 5:28

[GoogleCodeExporter]

I have the same issue on Raspberry pi model B rev 1. I'm running LMS and 
squeezelite on the pi, conected to a USB DAC.
I power on in the morning and start LMS and squeezelite. All works perfectly. 
When I come home from work 10 hours later, there is very distorted sound. I can 
vaguely hear the music through the noise. Tried this 3 days in a row and the 
same thing happens each time.

I can't see anything obvious in the squeezelite log.

I can still stream to my squeezebox classic without any issues, so I don't 
think its anything to do with LMS.

Original comment by [email protected] on 9 Sep 2013 at 4:18

[GoogleCodeExporter]

I tried powering the player off then on using the web interface power button.
I then tried "sudo service logitechmediaserver restart". Neither of these had 
any effect. The only way to stop the stuttering noise is to reboot the pi and 
then start squeezelite.

Original comment by [email protected] on 9 Sep 2013 at 6:28

[GoogleCodeExporter]

I wrote a simple shell script, which fixed the issue for me on OpenWRT Attitude 
on TP-Link MR3020. 
The script will whatch Alsa and LMS and just Soft Power off squeezelite, after 
10 min of not playing.
To use the script you have to adjust the LMS variable in line 4.
Also the script assumes squeezelite name and hostname match.

I run this script on startup via /etc/init.d

The script will also turn off the 3G LED while playing and turn it back on, if 
playing stopped. This is because I use the LED pin turn off and on my active 
speakers.

https://gist.github.com/hmeyer/6506906

Original comment by [email protected] on 11 Sep 2013 at 7:14

[GoogleCodeExporter]

Thanks, good to know that soft power-off squeezelite when inactive solves the 
issue. I'll adapt the script for my system and try it out.

Original comment by [email protected] on 11 Sep 2013 at 10:14

[GoogleCodeExporter]

I have the exact same issue as described by George (#11) with a raspberry pi 
with a USB DAC attached, it just produces a stuttering garbled sound, nothing 
in the logs and all my other squeezebox units works fine.. - a soft reset 
usually helps, but sometimes I have to try 2-3 times before it works..

Original comment by [email protected] on 9 Dec 2013 at 1:25

[GoogleCodeExporter]

chriz, the solution proposed by tutm (post #13) works for me. Two options: 
1) always soft power down squeezelite when you're finished listeneing (press 
the power button on the web interface).
2) Run a small background bash script on the pi to do this for you after a 
period of nothing playing (see tutm's script).

Original comment by [email protected] on 9 Dec 2013 at 2:27

[GoogleCodeExporter]

Thanks George, I'll give it a shot - and hope for a "real" solution sometime 
soon :)

Original comment by [email protected] on 10 Dec 2013 at 7:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've been suffering this problem for a long time using virtualised Debian 
SqueezeLite instances. I have been using the powersave plugin to configure the 
players to switch off after 30 minutes of in-activity but this doesn't always 
prevent the issue; http://bitflip.net/squeezebox/

I find the issue typically when using the Pandora plugin - and it seems to be 
mainly when the Pandora stream is paused. I'm only using libmpg123 and libFlac. 
A reboot of all the SqueezeLite instances in the sync group always fixes the 
issue.

Original comment by [email protected] on 4 Feb 2014 at 3:36

[GoogleCodeExporter]

I have the same issue on Debian 6 with flac playback from lms. The soft power 
down works (either through the GUI or scripted) but it would be nice to know 
what causes it.

Original comment by [email protected] on 7 Feb 2014 at 1:10

[GoogleCodeExporter]

Just a quick update, I installed this powersave plugin that turns off my Rpi 
when idle on my Logitech Media Server and seems to be a good workaround (I 
haven't had this issue for a week now):
http://bitflip.net/squeezebox/

Guess it's the same functionality as the script from #13, but this is a bit 
easier to install and use.. :)

Original comment by [email protected] on 10 Feb 2014 at 7:22

[GoogleCodeExporter]

I have had a similar problem.  With mine I get clicking in the audio.  I 
believe this to be more of an audio on linux problem though, as I also get this 
with another app, I think it was squeezeslave.  Both apps have more or less the 
same behavior, after I leave it on pause for several hours starting it back up 
results in noise. 

My fix has been to use a cron job to kill the process every day and restart it. 
 Not a very good fix, but it works for my use.  I will probably try the 
powersave plugin as that seems far more graceful.  

Original comment by [email protected] on 10 Feb 2014 at 7:00

[GoogleCodeExporter]

Same issue for me with a Pogoplug E02 with Arch Linux installed, squeezelite 
1.5, plugged into a Rega DAC, playing any type of content. I have to restart 
squeezelite every morning.

Original comment by [email protected] on 25 Feb 2014 at 10:56

[GoogleCodeExporter]

Hy, on my Odroid U3, Ubuntu 13.10 i have the same problem. after 4-6 hours of 
playing Internet radio i have a very garbage sound. and nothing in the log! 
after start and sotp the sound is okay. i test the same situation with 
MPD-player and with this i have no problem.
my settings:
 -n PLAYER01 -o squeezeli01 -d all=debug -a 4096:1024:16:0 -r 44100
there is already a solution for this?

Original comment by [email protected] on 24 Jul 2014 at 3:00

[GoogleCodeExporter]

What codec is this?  Have you tried alternative codecs if mp3?

Original comment by [email protected] on 24 Jul 2014 at 5:54

[GoogleCodeExporter]

thank you for your answer.
it is a mp3 stream, station FM4 see attachment. what do you mean with a 
alternativ codec - a other internet radio station? is there a internet radio 
station with a other stream then mp3? make it a difference to insert the -c 
<codec1>,<codec2> parameter?

THX

Original comment by [email protected] on 25 Jul 2014 at 6:16

Attachments:

• LMS-FM4.png

[GoogleCodeExporter]

yes I was wondering if changing to mpg123 made any difference.  There's nothing 
in squeezelite which I would expect to stop after 4 hours.  If you transcoded 
to flac then there could be a problem (if you don't use the logitech patched 
flac version), but otherwise don't understand the problem.

Original comment by [email protected] on 26 Jul 2014 at 10:11

[GoogleCodeExporter]

i hope we can found a solution for this problem, now i post it to the 
squeezebox forum maybe someone knows a solution:

http://forums.slimdevices.com/showthread.php?97046-Announce-Squeezelite-a-small-
headless-squeezeplay-emulator-for-linux-(alsa-only)&p=786908&viewfull=1#post7869
08

Original comment by [email protected] on 1 Aug 2014 at 5:29

[GoogleCodeExporter]

I have a similar problem. After rebooting RPi everything basically works. When 
I play e.g. an internet radio stream or mp3, after some hours (or sometimes 
minutes) I hear distorting noise. Usually, the problem is gone after some 
seconds, but it also happens that the output gets nearly completely silent and 
I only hear some noise about every 10 seconds.
Restarting squeezelite helps.
At least a workaround would be great, so squeezelite could play e.g. for 20 
hours and then do a reboot at night, if necessary.

Original comment by [email protected] on 22 Oct 2014 at 6:03

[GoogleCodeExporter]

I did some tests with multiple squeezelite instances, using the same USB sound 
card model (1 instance for 1 device), running the same internet stream, but 
with different squeezelite parameters on RPi device. At the moment it seems 
like the problem is solved for me.

Results:
"-a 80": Stream is OK for some hours, but then gets distorted or is silent.
"-a :::0": Stream is now running fine even after 16 hours playing.

Additionally, this might also help (not sure):
- /etc/modprobe.d/alsa-base.conf: options snd-hda-intel model=generic
- Set CPU governor to "performance", e.g. in crontab: @reboot echo -n 
performance | tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Original comment by [email protected] on 25 Oct 2014 at 6:29

[GoogleCodeExporter]

Update: Unfortunately not completely solved, but it's better than before. The 
audio output is basically fine, but produces distorted noise for some seconds, 
in irregular intervals (15 - 45 minutes), with no certain log entries.

Original comment by [email protected] on 25 Oct 2014 at 6:40

[GoogleCodeExporter]

So, I'm having this same problem, and haven't been able to sort out the problem.

I have two devices this is happening on, a Raspberry Pi Model B, and a 
Beagleboard-xM, both running debian (Raspian on the PI, and Debian Jessie on 
the bbxm). I'm running 
Squeezelite v1.6.5 compiled from source. Both devices are outputting to a USB 
DAC. Everything works fine, but after a long period of silence things stop 
working and the only fix is to restart squeezelite (turning off in 
squeezeserver, or restarting squeezeserver has no effect).

The run command I'm using is:
/usr/bin/squeezelite -n Office -m 00:00:00:00:00:31 -d all=info -f 
/var/log/squeezelite.log -o default:CARD=DAC -s <servername>

In my case, after squeezelite has been running for some time, when I go to play 
something I get no audio, then maybe a short sub second blip of sound, then 
nothing again for some minutes, then a blip, and so on. It seems to happen 
after 6 hours or so, and it happened once while I was listening to audio. It 
was playing, and then without any interaction it stopped playing, and started 
to blip little sub second chunks of audio every minute or two, exactly like it 
does after being idle (this happened after hours of listening).

I turned logging onto output=sdebug and generated a 1GB log file, and found the 
following behavior during the blipping audio part:

[17:56:11.424374] _output_frames:269 wrote 2048 frames
[17:56:11.425168] _output_frames:111 avail: 3456 frames: 2048 silence: 1
[17:56:11.425748] _output_frames:269 wrote 2048 frames
[17:56:11.426541] _output_frames:111 avail: 1408 frames: 1408 silence: 1
[17:56:11.427426] _output_frames:269 wrote 1408 frames
<stops logging anything>

<hear a blip of audio noise (less than one second)>
[17:59:27.857541] _output_frames:111 avail: 8655506 frames: 430080 silence: 0
[17:59:27.936032] _output_frames:269 wrote 430080 frames
[17:59:27.938565] _output_frames:111 avail: 8228951 frames: 2048 silence: 1
[17:59:27.940823] _output_frames:269 wrote 2048 frames
[17:59:27.942532] _output_frames:111 avail: 8226903 frames: 2048 silence: 1
[17:59:27.943692] _output_frames:269 wrote 2048 frames
[17:59:27.945431] _output_frames:111 avail: 8225119 frames: 2048 silence: 1
[17:59:27.947781] _output_frames:269 wrote 2048 frames
[17:59:27.948727] _output_frames:111 avail: 8223291 frames: 2048 silence: 1
[17:59:27.950955] _output_frames:269 wrote 2048 frames
<cut, continues to count down avail frames>
[17:59:34.781979] _output_frames:111 avail: 8742 frames: 2048 silence: 1
[17:59:34.782986] _output_frames:269 wrote 2048 frames
[17:59:34.783444] _output_frames:111 avail: 6694 frames: 2048 silence: 1
[17:59:34.784238] _output_frames:269 wrote 2048 frames
[17:59:34.785123] _output_frames:111 avail: 4867 frames: 2048 silence: 1
[17:59:34.785733] _output_frames:269 wrote 2048 frames
[17:59:34.786038] _output_frames:111 avail: 2819 frames: 2048 silence: 1
[17:59:34.786862] _output_frames:269 wrote 2048 frames
<log pauses again>

<blip of audio>
[18:02:51.202206] _output_frames:111 avail: 8655615 frames: 430080 silence: 0
[18:02:51.280850] _output_frames:269 wrote 430080 frames
[18:02:51.283719] _output_frames:111 avail: 8229060 frames: 2048 silence: 1
[18:02:51.285855] _output_frames:269 wrote 2048 frames
[18:02:51.287778] _output_frames:111 avail: 8227232 frames: 2048 silence: 1
[18:02:51.288785] _output_frames:269 wrote 2048 frames

And this continues to repeat until squeezelite is restarted.


As a further interest, I tried squeezeslave 1.3-390 (downloaded binary) on the 
pi, and it seems to work without any problems after weeks of usage? Presumably 
this would work on the bbxm but I haven't tried it yet.


I'd love to figure out whats going on here, so I'd be happy to guinea pig these 
systems if anyone has any ideas?

Original comment by [email protected] on 13 Dec 2014 at 9:37

[GoogleCodeExporter]

Thanks - that certainly gives me something to go on for the first time.  The 
available frames should never be that large.

Can you confirm what alsa options are being used - do you have the start of the 
debug which shows how the output is starting up?

Original comment by [email protected] on 14 Dec 2014 at 11:14

[GoogleCodeExporter]

Are you able to patch the code - if so try adding this:
diff --git a/output_alsa.c b/output_alsa.c
index aeb9d25..b5619ab 100644
--- a/output_alsa.c
+++ b/output_alsa.c
@@ -553,6 +553,8 @@ static void *output_thread(void *arg) {
                // restrict avail in writei mode as write_buf is restricted to period_size
                if (!alsa.mmap) {
                        avail = min(avail, alsa.period_size);
+               } else {
+                       avail = min(avail, alsa.buffer_size);
                }

                // avoid spinning in cases where wait returns but no bytes available (seen with pulse audio)

Otherwise can you email me and I will send you a test binary.

I've googled and there are reports of buggy alsa drivers returning very large 
numbers for available frames.  The apps which have reported seem to do 
something similar to ignore the report and use what is viewed as a sensible 
value.  The alternative is we treat this as an error and call the alsa recovery 
code.  If this first approach doesn't work then we can try that.

Original comment by [email protected] on 14 Dec 2014 at 11:41

[GoogleCodeExporter]

Excellent, I've applied that patch, and I'll let that run and see what happens 
and report back.

I've attached the start of the debug log in a text file that shows how the 
output is starting up.

Original comment by [email protected] on 15 Dec 2014 at 4:55

Attachments:

• debug.txt

[GoogleCodeExporter]

Good sign, after applying the patch, playing some music, and then leaving it 
paused for 12 hours, it started right back up and played today. That seems 
longer than I've ever noticed in the past. I'll post back after a few days use 
just to be sure. Thanks!

Original comment by [email protected] on 15 Dec 2014 at 6:07

[GoogleCodeExporter]

So... that patch seems to completely fix squeezelite running on my 
Beagleboard-xM, which is awesome. However I'm still having the issue on my 
Raspberry Pi with that patch applied. It is running a different (cheaper) usb 
DAC, and the Pi is running rasbian (debian wheezy) vs debian jessie on the 
Beagleboard, so there are some differences hardware and os wise. It has the 
exact same symptoms, after long period of not playing (serveral hours), it 
blips and doesn't play properly. The blips seem to happen more frequently than 
they did on the beagleboard however. 

I'll enable debug logging on the Pi wait for the issue and see what I can find 
(everything I posted before was from the beagleboard).

Original comment by [email protected] on 16 Dec 2014 at 4:52

[GoogleCodeExporter]

What about this more aggressive patch which will try to recover from an error 
if the available value is too large:

diff --git a/output_alsa.c b/output_alsa.c
index aeb9d25..3d49d3d 100644
--- a/output_alsa.c
+++ b/output_alsa.c
@@ -507,7 +507,7 @@ static void *output_thread(void *arg) {

                snd_pcm_sframes_t avail = snd_pcm_avail_update(pcmp);

-               if (avail < 0) {
+               if (avail < 0 || avail > alsa.buffer_size) {
                        if ((err = snd_pcm_recover(pcmp, avail, 1)) < 0) {
                                if (err == -ENODEV) {
                                        LOG_INFO("Device %s no longer available", output.device);


Note this does assume that you see the same thing with logging - that we get 
very large numbers for available frames.

Original comment by [email protected] on 16 Dec 2014 at 8:34

[GoogleCodeExporter]

So, things look a bit different in the debug output on the Pi. Here is a quick 
breakdown of what I'm seeing the log:

<squeezelite is paused for a number of hours>
[21:39:45.256303] _output_frames:111 avail: 3763 frames: 2048 silence: 1
[21:39:45.258223] _output_frames:269 wrote 2048 frames
[21:39:45.258983] _output_frames:111 avail: 3763 frames: 2048 silence: 1
[21:39:45.260882] _output_frames:269 wrote 2048 frames
[21:39:45.261610] _output_frames:111 avail: 2421 frames: 2048 silence: 1
[21:39:45.264529] _output_frames:269 wrote 2048 frames
[21:39:47.850849] output_flush:415 flush output buffer
<hit play (I think this is where it starts after hitting play, but not 100% 
sure)>
[21:40:03.128537] _output_frames:59 start buffer frames: 430080
[21:40:03.129195] _output_frames:111 avail: 3763 frames: 430080 silence: 0
[21:40:03.130281] _output_frames:144 track start sample rate: 44100 
replay_gain: 0
[21:40:03.131880] _output_frames:269 wrote 0 frames
[21:40:03.132765] output_thread:609 wrote 0 - sleeping
[21:40:03.144239] _output_frames:111 avail: 3763 frames: 430080 silence: 0
[21:40:03.146584] _output_frames:269 wrote 3763 frames
[21:40:03.147266] _output_frames:111 avail: 3763 frames: 426317 silence: 0
[21:40:03.148394] _output_frames:269 wrote 3763 frames
[21:40:03.150105] _output_frames:111 avail: 3763 frames: 422554 silence: 0
[21:40:03.151298] _output_frames:269 wrote 3763 frames
[21:40:03.151953] _output_frames:111 avail: 3763 frames: 418791 silence: 0
[21:40:03.154190] _output_frames:269 wrote 3763 frames
[21:40:03.154868] _output_frames:111 avail: 3763 frames: 415028 silence: 0
[21:40:03.157054] _output_frames:269 wrote 3763 frames
...
<this counts down the frames value within half a second, then switches to 
silence>
<this produces a blip of garbled sounding audio>
[21:40:03.517325] _output_frames:111 avail: 3763 frames: 12387 silence: 0
[21:40:03.518495] _output_frames:269 wrote 3763 frames
[21:40:03.520258] _output_frames:111 avail: 3763 frames: 8624 silence: 0
[21:40:03.521427] _output_frames:269 wrote 3763 frames
[21:40:03.523245] _output_frames:111 avail: 3763 frames: 4861 silence: 0
[21:40:03.524469] _output_frames:269 wrote 3763 frames
[21:40:03.527284] _output_frames:111 avail: 3763 frames: 1098 silence: 0
[21:40:03.529077] _output_frames:269 wrote 1098 frames
[21:40:03.529782] _output_frames:111 avail: 3763 frames: 2048 silence: 1
[21:40:03.531654] _output_frames:269 wrote 2048 frames
[21:40:03.532609] _output_frames:111 avail: 3763 frames: 2048 silence: 1
[21:40:03.534627] _output_frames:269 wrote 2048 frames
[21:40:03.535408] _output_frames:111 avail: 3763 frames: 2048 silence: 1
[21:40:03.537286] _output_frames:269 wrote 2048 frames
...
<silence frames repeat until it stops and pauses>
[21:40:04.159600] _output_frames:111 avail: 3758 frames: 2048 silence: 1
[21:40:04.161499] _output_frames:269 wrote 2048 frames
[21:40:04.162236] _output_frames:111 avail: 1710 frames: 1710 silence: 1
[21:40:04.164253] _output_frames:269 wrote 1710 frames
<blip of audio again and it repeats>
[21:40:22.031624] _output_frames:111 avail: 3763 frames: 430080 silence: 0
[21:40:22.033475] _output_frames:269 wrote 3763 frames
[21:40:22.034733] _output_frames:111 avail: 3763 frames: 426317 silence: 0
[21:40:22.037181] _output_frames:269 wrote 3763 frames
[21:40:22.037820] _output_frames:111 avail: 3763 frames: 422554 silence: 0
[21:40:22.040152] _output_frames:269 wrote 3763 frames
[21:40:22.040795] _output_frames:111 avail: 3763 frames: 418791 silence: 0
[21:40:22.043359] _output_frames:269 wrote 3763 frames

Seems to do this every 20 second or so.

I've attached the startup of the debug log, as well as the chunk that shows the 
details of the above behavior. 


I guess this looks different then the available frames problem, so the above 
patch probably won't help? Let me know what you think or if there is anything 
else I can do to test. And thanks for all your help thus far!

Original comment by [email protected] on 17 Dec 2014 at 3:40

Attachments:

• debug-pi-startup.txt
• debug-pi-blip.txt

[GoogleCodeExporter]

Hi - is there any reason for always going via the alsa resampling layer - could 
you try using the output device direct with -o hw:CARD=DAC

If the dac only does 48k then perhaps resample with squeezelite?

Does this make any difference?  I'm trying to find out why this is not seen by 
other people.  [my pi with a i2s dac recovers all the time after a day on 
pause, but thats a different driver.  I will test again with a usb dac]

Original comment by [email protected] on 17 Dec 2014 at 7:40

[GoogleCodeExporter]

Yeah, I'm only using the alsa resampling layer because of ignorance (I don't 
really know what I'm doing here in terms of alsa). I suppose I was starting it 
that way because that was what was listed from ./squeezelite -l

I've started it up with -o hw:CARD=DAC and I'll report back tomorrow with how 
that goes.

Interesting the DAC reports differently using that as the startup:

Hardware PCM card 1 'USB Audio DAC' device 0 subdevice 0
Its setup is:
...
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 1764
  period_size  : 441
  period_time  : 10000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 441
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1764
  silence_threshold: 0
  silence_size : 0
  boundary     : 1849688064
  appl_ptr     : 0
  hw_ptr       : 0

Original comment by [email protected] on 18 Dec 2014 at 5:02

[GoogleCodeExporter]

OK - will await feedback.

I've applied a variant of the patch in post #34 to git so this should mean the 
case of large available frames can be recovered from - as seen on your 
Beagleboard-xM.

Original comment by [email protected] on 18 Dec 2014 at 8:09

[GoogleCodeExporter]

Interesting, it looks like the problem doesn't show up when using -o hw:CARD=DAC

It pretty consistently did it within about 6 hours before, but it's a day now, 
and it's running perfectly fine, so I think that solves the issue. I also took 
a quick look at squeezeslave which I was using that didn't have the issue, and 
it lists the cards by number, but they link to hw(0,1) or whatever devices, so 
that might have been why it worked without issue with it.

So that solves the issue for me, and probably anyone else who was having the 
same problem if they change the output device from default to hw.

If there is anything else you'd like me to test with this particular hardware 
setup let me know, but otherwise you can probably close this issue (and maybe a 
few of the others tickets that look like they might be the same issue).

Thanks so much for all the help, and for squeezelite!

Original comment by [email protected] on 19 Dec 2014 at 1:51

[GoogleCodeExporter]

This is great! I installed squeezelite on my RPi B+ a week ago, never had this 
issue with the internal audio, but ran into it on the USB DAC. I enabled debug 
logs yesterday but then came across this thread. While it is very useful to 
know that hw:CARD=DAC solves the issue, I would like squeezelite to NOT lock 
the hardware sound device all for itself.

triode, would you need any more info to troubleshoot this issue? In the 
meantime I have switched over to squeezeslave 1.3-390 too see if it fixes the 
issue on RPi B+.

Thank you for all your help, I prefer squeezelite over mpd!

Original comment by [email protected] on 19 Dec 2014 at 3:31

[GoogleCodeExporter]

I also confirm that switching default to hw fix Internet radio playing 
overnight on RPi and Pogoplug Mobile. Great job thank you.

Original comment by [email protected] on 19 Dec 2014 at 5:52

[GoogleCodeExporter]

@sushyad

Can you test with a build based on the latest git (i.e. can you compile for 
yourself?)  I would like to get any reports of it with the large available 
frames patch applied.

If you can then reproduce with an alsa plug layer can you try different 
settings for bit depth and mmap to see if this impacts it.  At this point I 
suspect squeezelite is exercising the alsa layer in ways other apps arn't, but 
the bug is in alsa - however if we can find then we can see if it can be worked 
around.

Original comment by [email protected] on 19 Dec 2014 at 5:57

[GoogleCodeExporter]

Hi any news on this issue? I have the same problem, but after "hw:CARD=DAC" 
squeezelite is not starting, even on force-reload. Than I edit the config with 
"hw:CARD=Device" and it works, but stops playing after a few hours. I have 4 
Rpi B+ with USB Soundcard C-Media

Original comment by [email protected] on 24 Feb 2015 at 11:40