[Bug 784803] New: alsasrc: Incorrectly timestamps buffers when pipeline is using a network clock

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 784803
           Summary: alsasrc: Incorrectly timestamps buffers when pipeline
                    is using a network clock
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: gstblub at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 355339
  --> https://bugzilla.gnome.org/attachment.cgi?id=355339&action=edit
netclientclock/ptpclock: Set clock-type property to "other"

The alsasrc plugin looks at the selected clock and checks if it's a clock based
on the monotonic clock.  The problem is, the network clocks derive from the
system clock and their clock-type property still defaults to the monotonic
clock.  If the pipeline clock is such a network clock, the alsasrc plugin then
uses the timestamps provided by alsa (which are based on the monotonic clock)
to timestamp the buffers it produces, which won't match what the pipeline
expects.

There are multiple ways to fix this issue, but I'm not sure what the right
approach is:
1. alsasrc should check if the clock *is* of type GstSystemClock, rather than
merely checking whether it is or potentially was derived from that class
2. The network clock implementations should set the clock-type property to
"other" by default
3. The GstSystemClock and network clock implementations should be based off
another common base class, and only the GstSystemClock class would have the
clock-type property

The attached patch fixes it by implementing #2.

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