SamS wrote: > Steen and Greg, > > Here is the source of my issue: > http://bugs.slimdevices.com/show_bug.cgi?id=10237 > > It's a culprit of SqueezePlay. Basically, the buffer for each 16/44 > FLAC track runs out at -0:10 seconds, at which time LMS sends a big > spike of data which causes the audible dropout. This also explains why > hi-rez tracks experience this phenomenon around -0:04, because the > buffer holds less of the track due to size. > > What pCP or LMS settings could fix this reliably? > > Another fellow confirms here: > http://forums.slimdevices.com/showthread.php?97803-piCorePlayer-Squeezelite-on-Microcore-linux-An-embedded-OS-in-RAM-with-Squeezelit&p=791870&viewfull=1#post791870
Just a thought - it might be because your network and LMS are too good, and/or the squeezelite buffers are set too large. This might cause the pi and squeezelite to be completely swamped by a massive surge of network traffic as a huge chunk of the next track is sent very quickly by LMS, sufficient that the time-critical squeezelite thread pushing the (already buffered) remains of the current track to the output device doesn't get a look in for a bit. ------------------------------------------------------------------------ utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=97803 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
