[Bug 755623] New: audiomixer: Using absolute clock times results in 0..now buffers to be rendered at once, stalling the pipeline

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755623

            Bug ID: 755623
           Summary: audiomixer: Using absolute clock times results in
                    0..now buffers to be rendered at once, stalling the
                    pipeline
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: hfink at toolsonair.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 312142
  --> https://bugzilla.gnome.org/attachment.cgi?id=312142&action=edit
Reproducing test case

Consider the following test pipeline:

audiotestsrc is-live=TRUE wave=4 ! \
audio/x-raw,format=S16LE,rate=48000,channels=2 ! \
audiomixer start-time-selection=1 !\
queue max-size-time=%u  max-size-buffers=0 max-size-bytes=0 !\
fakesink async=FALSE"

When using absolute clock times (i.e. gst_element_set_base_time=0 and
gst_element_set_start_time=none on the pipeline) this will result in a lot of
buffers from the past to be rendered. I.e. look at the following log output: 

0:00:00.058614157 20696      0x2069850 LOG          audioaggregator
gstaudioaggregator.c:1170:gst_audio_aggregator_aggregate:<audiomixer0> Starting
to mix 480 samples for offset 0 with timestamp 4:21:04.348533174
0:00:00.058656691 20696      0x2069850 DEBUG        audioaggregator
gstaudioaggregator.c:938:gst_audio_aggregator_fill_buffer:<audiomixer0:sink_0>
Buffer resynced: Pad offset 751888729, current audio aggregator offset 0
0:00:00.058670729 20696      0x2069850 LOG          audioaggregator
gstaudioaggregator.c:945:gst_audio_aggregator_fill_buffer:<audiomixer0:sink_0>
Queued new buffer at offset 751888729
0:00:00.058680856 20696      0x2069850 LOG          audioaggregator
gstaudioaggregator.c:1341:gst_audio_aggregator_aggregate:<audiomixer0> pushing
outbuf 0x7f96a4007700, timestamp 4:21:04.348533174 offset 0
0:00:00.058711097 20696      0x2069850 LOG          audioaggregator
gstaudioaggregator.c:1348:gst_audio_aggregator_aggregate:<audiomixer0> pushed
outbuf, result = ok
0:00:00.058759009 20696      0x2069850 LOG          audioaggregator
gstaudioaggregator.c:1170:gst_audio_aggregator_aggregate:<audiomixer0> Starting
to mix 480 samples for offset 480 with timestamp 0:00:00.010000000
0:00:00.058777028 20696      0x2069850 LOG          audioaggregator
gstaudioaggregator.c:1341:gst_audio_aggregator_aggregate:<audiomixer0> pushing
outbuf 0x7f96a4007810, timestamp 0:00:00.010000000 offset 480
0:00:00.058797562 20696      0x2069850 LOG          audioaggregator
gstaudioaggregator.c:1348:gst_audio_aggregator_aggregate:<audiomixer0> pushed
outbuf, result = ok
0

It looks like the first rendered sample(s) use the correct timestamps
(4:21:04.348533174), but then something happens, and the mixer starts at zero
(0.01) again.

I have attached a simple test program to reproduce this issue. You can get the
above log output using GST_DEBUG=audioaggregator:6. This program simply
launches the above pipeline, and sets element_base_time=0 and start_time=none.
In the example code you can also optionally set USE_PTP_CLOCK=1 to use a ptp
clock with the domain PTP_DOMAIN. Because of the high absolute timestamps with
the PTP clock, using a PTP clock will result in constant stalling of the
pipeline, because audiomixer is not able to catch up with rendering
0...PTP_ABSOLUTE_TIME. When using system clock, the absolute times are not that
high, and the pipeline will eventually stop stalling, when
0..SYS_CLOCK_ABSOLUTE_TIME

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.