alsasrc reports very large DISCONT after 7h20m
Brendan Shanks
brendan.shanks at teradek.com
Fri Aug 17 01:17:34 UTC 2018
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.
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.
7:20:37.871464957 1919 0xda0180 WARN audiobasesrc
gstaudiobasesrc.c:842:gst_audio_base_src_create:<alsasrc1> create DISCONT
of 10501920 samples at sample 1268840640
7:20:37.871751552 1919 0xda0180 WARN audiobasesrc
gstaudiobasesrc.c:847:gst_audio_base_src_create:<alsasrc1> warning: Can't
record audio fast enough
7:20:37.871819092 1919 0xda0180 WARN audiobasesrc
gstaudiobasesrc.c:847:gst_audio_base_src_create:<alsasrc1> warning: Dropped
10501920 samples. This is most likely because downstream can't keep up and
is consuming samples too slowly.
7:20:37.871974254 1919 0xda0180 INFO GST_ERROR_SYSTEM
gstelement.c:1938:gst_element_message_full_with_details:<alsasrc1> posting
message: Can't record audio fast enough
7:20:37.872104000 1919 0xda0180 INFO GST_ERROR_SYSTEM
gstelement.c:1965:gst_element_message_full_with_details:<alsasrc1> posted
warning message: Can't record audio fast enough
7:20:37.874166283 1919 0xecb380 WARN alsa
gstalsasink.c:983:xrun_recovery:<alsasink1> xrun recovery -32: Broken pipe
7:20:38.691488200 1919 0xda0180 WARN audiobasesrc
gstaudiobasesrc.c:842:gst_audio_base_src_create:<alsasrc1> create DISCONT
of 38400 samples at sample 1268880000
7:20:38.691657779 1919 0xda0180 WARN audiobasesrc
gstaudiobasesrc.c:847:gst_audio_base_src_create:<alsasrc1> warning: Can't
record audio fast enough
7:20:38.691715319 1919 0xda0180 WARN audiobasesrc
gstaudiobasesrc.c:847:gst_audio_base_src_create:<alsasrc1> warning: Dropped
38400 samples. This is most likely because downstream can't keep up and is
consuming samples too slowly.
7:20:38.691853783 1919 0xda0180 INFO GST_ERROR_SYSTEM
gstelement.c:1938:gst_element_message_full_with_details:<alsasrc1> posting
message: Can't record audio fast enough
7:20:38.691966738 1919 0xda0180 INFO GST_ERROR_SYSTEM
gstelement.c:1965:gst_element_message_full_with_details:<alsasrc1> posted
warning message: Can't record audio fast enough
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.
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:
$ cat /proc/asound/card0/pcm1p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
avail_min: 480
start_threshold: 9600
stop_threshold: 9600
silence_threshold: 0
silence_size: 0
boundary: 1258291200
'boundary' is calculated in the kernel, by multiplying buffer_size * 2 up
to LONG_MAX (<https://elixir.bootlin.com/linux/v4.18/source/sound/core/
pcm_native.c#L751>). This means 'boundary' is much larger on a 64-bit
system, maybe the DISCONT wouldn't happen there.
Any ideas/help is much appreciated.
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180816/302b6cad/attachment.html>
More information about the gstreamer-devel
mailing list