alsasrc: Incorrectly timestamps buffers when pipeline is using a network clock
Submitted by GstBlub
Link to original bug (#784803)
Description
Created attachment 355339
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:
- alsasrc should check if the clock is of type GstSystemClock, rather than merely checking whether it is or potentially was derived from that class
- The network clock implementations should set the clock-type property to "other" by default
- 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
.
Patch 355339, "netclientclock/ptpclock: Set clock-type property to "other"":
0001-netclientclock-ptpclock-Set-clock-type-property-to-o.patch