[Bug 699744] New: timestamps provided by audiosrc subclass not used when running under slave clock

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=699744
  GStreamer | gst-plugins-base | 1.x

           Summary: timestamps provided by audiosrc subclass not used when
                    running under slave clock
    Classification: Platform
           Product: GStreamer
           Version: 1.x
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: alexas at axis.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Under the scenario that you have an alsasrc under a monotonic system clock we
are supposed to use the driver timestamps instead of running time for the
buffers. There are several bugs here: This mechanism isn't triggered at all:

in gst_alsasrc_change_state it looks like we check for a monotonic system
clock, but the value we actually check is src->clk (GstAudioBaseSrc's src
member) which as far as I understand is always of type other because it is an
audiosrcclock.

Ok, so I tried changing that to clk = GST_ELEMENT_CLOCK(element); which I think
is correct. Now I get the read function to return timestamps, but these are not
used since the audiobasesrc is slaved. In gst_audio_base_src_create we get this
timestamp value from gst_audio_ring_buffer_read and set rb_timestamp correctly.
But then we don't use rb_timestamp at all until the case where we are not
slaved.

The reason I won't submit a patch directly is because I am confused about where
the bug is and what the expected bahaviour is here. We depend on the driver
timestamps being unmodified (ie not subtracted by the base time) when they
leave the audio src, but is this the intention when returning time stamps from
gst_audio_base_src_create?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.