Greg Erskine wrote: > 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
Hi Greg. I understood Squeezelite to be based on Squeezeplay, so I was thinking a glitch associated with Squeezeplay could have carried over? My network is fairly simple, no subnets. Only one instance of LMS running. All Squeeze devices hard-wired, except for one Radio. No instances of this issue on standard Squeezedevices, or via optical/coax of my pCP using the HiFiBerry Digi. utgg wrote: > 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. Seems reasonable. My LAN is very robust. All Cat6 cabling, short runs, Gigabit switches. Never any buffering or dropout issues, and I've been a Squeezebox user for 9+ years. JackOfAll wrote: > Just throwing things out there while I think of them.... > > 1. Crossfade. > 2. Up/resampling (On an older version of squeezelite, when the buffer > for new track starts being filled, 10s before the old track ends, there > was a lock around the resample code that could cause the audio buffer to > underrun. Should get a XRUN in the squeezelite log, if it is that.) > 3. Steen, does the squeezelite audio output thread run with RT PRIO -46 > on pico? (ie. the default) (Sorry, don't have pico installed on a Pi at > the moment to look myself.) > > OP, with the USB DAC... buffer... I use "-a 16384:4096" when running a > USB DAC from Pi. Try it. 1. I disable Crossfade/Smart Crossfade always. A while back I was troubleshooting this and occasionally fixed this problem by enabling Smart Crossfade, but setting the duration to 0s. That didn't reliably work, so I'm back to no crossfade of any kind. 2. I am not using any up sampling or resampling. Regarding "-a 16384:4096" , we have a fix! I tested this, and have not been able to duplicate the dropout/glitch. I was previously using the 80:4 default. I'll have to continue testing. JackOfAll wrote: > Good! Really need that thread that feeds ALSA driver with data to be > running higher prio than the others in the squeezelite process, > especially when feeding a USB DAC, which is typically "sucking up" CPU > cycles with a kworker thread processing the interrupts from the > hardware. I only understand some of this, but I like where you're going :) Guys, I would be happy to run logs and share, but please be specific on exactly how to run the logs. I don't even have PUTTY on this machine, so if I need to capture logging, please advise in very basic steps. ------------------------------------------------------------------------ SamS's Profile: http://forums.slimdevices.com/member.php?userid=9261 View this thread: http://forums.slimdevices.com/showthread.php?t=97803 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
