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
Hey SamS, Just putting some ideas out there! We don't use SqueezePlay, we use Squeezelite. You have tried big buffers, 8000 instead of 80. Even so, that would just be masking your issue. We have to work out why the buffer is not being filled in timely manner. Can you describe your network? Are you using subnets? Do you have both LMS up at the same time? pCP will just use the first one it finds. Try netstat -nt on the Pi to see it's tcp connections. Port #3483 is the LMS server. BTW: I use an original RPi with only 256mb as my LMS, pCP uses wifi and standard buffer settings. I have a dozen RPi and I just grab one, stick in a SD card and it just works. regards Greg ------------------------------------------------------------------------ Greg Erskine's Profile: http://forums.slimdevices.com/member.php?userid=7403 View this thread: http://forums.slimdevices.com/showthread.php?t=97803 _______________________________________________ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
