Rapid (~80mS) sample repeat - like skipping CD play

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Time - usually >8 hours of play, sometimes days

What do you see instead?
10-second sample of resulting audio: 
https://dl.dropboxusercontent.com/u/91727438/squeezelite_armv6hf_v1.6.4_on_PiB%2
B.ogg

What version of the product are you using?
 - squeezelite_armv6hf_v1.6.4

On what operating system?
 - Occurs on both current LMDE x86_64 Debian and current Raspbian on PiB+.

Please provide any additional information below.
 - Occurs with or without pulseaudio running.  If with pulse, pavucontrol suggests rapid open/close of playback source (squeezelite output) channel.
 - Only fix is to kill running instance and restart another.
 - Other machines, sync'd or unsync'd, are unaffected.
 - -a 40::16 CLI option makes no difference.

Original issue reported on code.google.com by gtbecke...@gmail.com on 20 Sep 2014 at 6:54

Attachments:

• squeezelite_armv6hf_v1.6.4_on_PiB+.ogg

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

What version of the product are you using?
 - squeezelite-x86-64 v1.6.4 and squeezelite-armv6hf v1.6.4

Original comment by gtbecke...@gmail.com on 20 Sep 2014 at 7:02

[GoogleCodeExporter]

What codec is this with - does this impact it?  I don't see this on other 
devices so need to narrow down what it is specific to.

Original comment by trio...@btinternet.com on 20 Sep 2014 at 9:02

[GoogleCodeExporter]

I've just forced -c mad on all players; not sure which MP3 codec was the 
default.

-c mpg runs normally on x86-64 machines but, on the PiB+, starting squeezelite 
with -c mpg immediately stops the LMS play running on an x86-64 machine; an LMS 
play restart doesn't last but a few seconds, so -c mad on the PiB+ seems 
necessary.

I'll watch this for a few days and report again.

Original comment by gtbecke...@gmail.com on 21 Sep 2014 at 3:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Still see the repeating, both with mad and mpg.  An allocation failure is 
persistent, and the buffer flushes, as below, are frequent.

If I wait long enough, the repeating sometimes ultimately ends, as if a 
repeatedly-failing command eventually succeeds.

The following log segment is from an x86-64 machine; The PiB+ log is 
essentially identical.

/usr/bin/squeezelite-x86-64 -n Tom -o pulse -c mad -f ~/log/squeezelite.log -a 
:::0 -d output=info 
[19:47:39.564325] output_init_alsa:638 init output
[19:47:39.564409] output_init_alsa:661 requested alsa_buffer: 40 alsa_period: 4 
format: any mmap: 0
[19:47:39.572238] output_init_common:402 supported rates: 192000 176400 96000 
88200 48000 44100 32000 24000 22500 16000 12000 11025 8000 
[19:47:39.572342] output_init_alsa:671 unable to lock memory: Cannot allocate 
memory
[19:47:39.573977] output_thread:465 open output device: pulse
[19:47:39.575975] alsa_open:234 opened device pulse using format: S32_LE sample 
rate: 44100 mmap: 0
[19:47:39.576011] alsa_open:313 buffer: 40 period: 4 -> buffer size: 1764 
period size: 441
[19:47:39.579420] output_flush:415 flush output buffer
[19:47:41.272368] _output_frames:144 track start sample rate: 44100 
replay_gain: 0
[20:10:00.015163] _output_frames:67 skip 4013 of 4013 frames
[21:42:09.967347] output_flush:415 flush output buffer
[21:42:11.490484] _output_frames:144 track start sample rate: 44100 
replay_gain: 0
[21:52:19.018888] output_flush:415 flush output buffer
[21:52:20.544554] _output_frames:144 track start sample rate: 44100 
replay_gain: 0
...

Original comment by gtbecke...@gmail.com on 24 Sep 2014 at 10:13

[GoogleCodeExporter]

Flush output buffer will occur when starting a new track.  The skip entry is 
probably due to sychronisation - are the players synced?

Original comment by trio...@btinternet.com on 25 Sep 2014 at 6:47

[GoogleCodeExporter]

Yes, players are sync'd so that explains the regular flush.  Is the memory 
allocation failure a concern?

Original comment by gtbecke...@gmail.com on 25 Sep 2014 at 7:07

[GoogleCodeExporter]

Yes memory allocation failure is a concern - don't see in this debug through.  
The "unable to lock memory: Cannot allocate memory" is not a problem - just 
means you are not running as root or with permissions to do this.

Original comment by trio...@btinternet.com on 25 Sep 2014 at 7:42

[GoogleCodeExporter]

I've got the same issue. In my case it starts after about 20-30 minutes of 
playing time. Only solution is to kill the instance and start another one.

- CuBox-i2
- HDMI audio
- Squeezelite-r130.ec0d566-1-armv7h.pkg.tar.xz
- ALSA buffer set to 80ms (to avoid buffer underrun)

Original comment by robin...@gmail.com on 3 Jan 2015 at 7:04

[GoogleCodeExporter]

HDMI audio on imx6 did have a problem with mmap - are you using "-a :::0" on 
the command line, or equivalent (mmap set to 0)

Original comment by trio...@btinternet.com on 3 Jan 2015 at 7:10

[GoogleCodeExporter]

Thanks for your fast response! Didn't get a notification of your msg (forgot to 
click the star).

I hadn't altered the mmap setting. Is it active by default? Just changed it and 
curious to see if it solves the problem! 

/usr/bin/squeezelite -n CuBox -o hw:CARD=imxhdmisoc -a 80:::0 -f 
/var/log/squeezelite.log -d slimproto=info

Changing the output to s/pdif is also an option...

Original comment by robin...@gmail.com on 7 Jan 2015 at 10:27