Comments (47)
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
from squeezelite.
Are there any debug messages in the case of the garbage noise?
Original comment by [email protected]
on 23 Jun 2013 at 5:06
from squeezelite.
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
from squeezelite.
[deleted comment]
from squeezelite.
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:
from squeezelite.
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
from squeezelite.
[deleted comment]
from squeezelite.
[deleted comment]
from squeezelite.
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
from squeezelite.
The library installed are libmpg123 and libFlac.
Original comment by [email protected]
on 8 Sep 2013 at 5:28
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
[deleted comment]
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
What codec is this? Have you tried alternative codecs if mp3?
Original comment by [email protected]
on 24 Jul 2014 at 5:54
from squeezelite.
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:
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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:
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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:
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
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
from squeezelite.
@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
from squeezelite.
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
from squeezelite.
Related Issues (20)
- Synced squeezelite pauses every 35 seconds HOT 1
- OS X - squeezelite asks always for firewall password
- Squeezelite disconnects from mysb.com
- Incorrect sample rate for shoutcast stations combined with resampling and pipe out = wrong playout speed HOT 1
- Core dumped
- A bug in dynamic library loading (Linux version)
- Crackle on DSD files HOT 4
- Feature Request - Power on and off on LMS to toggle GPIO pin on raspberry
- Raspberry Pi: Distorted sound in random intervals for some seconds HOT 11
- Static build forRaspberry/OpenELEC 5 possible? HOT 2
- Squeezelite sound output stops after a few hours on Armv5 Pogoplug with Arch HOT 5
- ignore some files in the tree HOT 1
- [PATCH] fedora: need ffmpeg include path HOT 2
- Does squeezelite blocks raspberrypi gpios?
- Squeezelite Win
- Build an RPM package
- Squeezelite v1.8 not working on 4 channel iec958 interface HOT 1
- patches to build on musl libc
- Build number from the main download files - 1.7 or 1.8
- Squeezelite Armv6hf will not pause when sending power 0 command through nc HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from squeezelite.