<div dir="ltr"><div>My application is capturing and streaming audio/video, but I've reproduced this problem with a simple test app that's essentially implementing 'alsasrc ! tee name=t ! queue ! fakesink t. ! queue ! alsasink'. Note that the alsasrc is capturing from a dsnoop device, and alsasink is playing to a dshare device.<br></div><div><br></div><div>Consistently, after 7 hours 20 minutes, the alsasrc reports a large DISCONT. It's capturing at 48 kHz, so the number of samples "dropped" is always around 3-4 minutes worth.<br></div><div><br></div><div>7:20:37.871464957 1919 0xda0180 WARN audiobasesrc gstaudiobasesrc.c:842:gst_<wbr>audio_base_src_create:<<wbr>alsasrc1> create DISCONT of 10501920 samples at sample 1268840640<br>7:20:37.871751552 1919 0xda0180 WARN audiobasesrc gstaudiobasesrc.c:847:gst_<wbr>audio_base_src_create:<<wbr>alsasrc1> warning: Can't record audio fast enough<br>7:20:37.871819092 1919 0xda0180 WARN audiobasesrc gstaudiobasesrc.c:847:gst_<wbr>audio_base_src_create:<<wbr>alsasrc1> warning: Dropped 10501920 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.<br>7:20:37.871974254 1919 0xda0180 INFO GST_ERROR_SYSTEM gstelement.c:1938:gst_element_<wbr>message_full_with_details:<<wbr>alsasrc1> posting message: Can't record audio fast enough<br>7:20:37.872104000 1919 0xda0180 INFO GST_ERROR_SYSTEM gstelement.c:1965:gst_element_<wbr>message_full_with_details:<<wbr>alsasrc1> posted warning message: Can't record audio fast enough<br>7:20:37.874166283 1919 0xecb380 WARN alsa gstalsasink.c:983:xrun_<wbr>recovery:<alsasink1> xrun recovery -32: Broken pipe<br>7:20:38.691488200 1919 0xda0180 WARN audiobasesrc gstaudiobasesrc.c:842:gst_<wbr>audio_base_src_create:<<wbr>alsasrc1> create DISCONT of 38400 samples at sample 1268880000<br>7:20:38.691657779 1919 0xda0180 WARN audiobasesrc gstaudiobasesrc.c:847:gst_<wbr>audio_base_src_create:<<wbr>alsasrc1> warning: Can't record audio fast enough<br>7:20:38.691715319 1919 0xda0180 WARN audiobasesrc gstaudiobasesrc.c:847:gst_<wbr>audio_base_src_create:<<wbr>alsasrc1> warning: Dropped 38400 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.<br>7:20:38.691853783 1919 0xda0180 INFO GST_ERROR_SYSTEM gstelement.c:1938:gst_element_<wbr>message_full_with_details:<<wbr>alsasrc1> posting message: Can't record audio fast enough<br>7:20:38.691966738 1919 0xda0180 INFO GST_ERROR_SYSTEM gstelement.c:1965:gst_element_<wbr>message_full_with_details:<<wbr>alsasrc1> posted warning message: Can't record audio fast enough<br></div><div><br></div><div><br></div><div>There's no sign that this is due to an actual xrun when capturing from
the ALSA device, it seems to be some kind of clock/timing problem. (The alsasink does xrun though.) The pipeline clock is GstSystemClock. Hardware is an Ambarella SoC, it's very possible there's problems in hardware/drivers. ntpd is running on the system, and time seems to be accurate.<br></div><div><br></div><div><br></div><div>Not sure about this, but my guess for where the 7h20m time (and number of samples) comes from is related to the ALSA 'boundary' parameter, which can be viewed with:</div><div><br></div><div>$ cat /proc/asound/card0/pcm1p/sub0/<wbr>sw_params <br>tstamp_mode: NONE<br>period_step: 1<br>avail_min: 480<br>start_threshold: 9600<br>stop_threshold: 9600<br>silence_threshold: 0<br>silence_size: 0<br>boundary: 1258291200<br></div><div><br></div><div>'boundary' is calculated in the kernel, by multiplying buffer_size * 2 up to LONG_MAX (<<a href="https://elixir.bootlin.com/linux/v4.18/source/sound/core/pcm_native.c#L751" target="_blank">https://elixir.bootlin.com/<wbr>linux/v4.18/source/sound/core/<wbr>pcm_native.c#L751</a>>). This means 'boundary' is much larger on a 64-bit system, maybe the DISCONT wouldn't happen there.</div><div><br></div><div>Any ideas/help is much appreciated.<br></div><div><br></div><div>Brendan<br></div></div>