bpa wrote: > I can confirm when I add the command line option "-b 20000:60000" - the > files plays OK. It looks like ALSA is unable to play the 325.8KHz > stream unless it has big enough buffers for high sample rate streams. > This may be specific to my setup when my USB DAC can only go up to 96kHz > and ALSA will have to resample. > > It looks like this problem has nothing to do with LMS or PCP..
Interestingly (or not) I find that the issue described in this thread appears to be applicable to SqueezePlay as well. The 352,800 Hz sample rate stream does for it. It'll play "from scratch", but if the stream is paused it will not resume. Nor will it seek, or resume after a failed seek attempt. It will cope with 176,400 Hz, and 192,000 Hz. Informed by your finding, I rebuilt SqueezePlay after increasing the size of the decoded audio buffer (-DECODE_AUDIO_BUFFER_SIZE- in -src/audio/decode/decode_priv.h-). Normal service appears to have been resumed. At present, the buffer is set at 10 seconds of decoded audio, at 44,100 Hz. That would be reduced to 1.125 seconds at 352,800 Hz. I don't know what the underlying constraint is, but it seems 1.125 seconds just isn't enough. I don't know what the optimum choice would be, perhaps there may be something else in SqueezePlay that is waiting on a minimum amount of available audio. There's no command line switch or environment variable available that can increase the buffer size. Perhaps something for @ralphy to consider in the fullness of time. This experimentation has been done on macOS, which uses PortAudio, not Alsa, and without any resampling. No attached DAC. ------------------------------------------------------------------------ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113234 _______________________________________________ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
