Bogus timestamps produced by an audiosrc?
Carlos Rafael Giani
dv at pseudoterminal.org
Thu Jul 11 10:43:51 PDT 2013
I have been using a pipeline with an alsasrc and a monotonic
GstSystemClock explicitely set as the pipeline clock. On the PC,
everything works fine. On a platform with an ARM3352 SoC , playback
I found out why: the alsasrc gets the timestamps for its produced
buffers from the ALSA API if the pipeline clock is monotonic. On the PC,
that works, since the pipeline clock's time and the alsasrc timestamps
fit together. But on the SoC, the driver timestamps are way off (for
example, current pipeline clock is at 3:04:00 , and the next alsasrc
timestamp is something like 379894:11:41).
From what I could see in the code, the driver timestamps are expected
to use the same time base as Linux' monotonic system clock. At least I
do not see where in the alsasrc code it would be applying timestamp
transformations to let the driver timestamps match the monotonic
pipeline clock. If so, is it guaranteed by ALSA that the driver
timestamps use the monotonic clock timebase? I cannot find this
mentioned in the ALSA docs.
For now, I make sure that the driver timestamps are never used. Also,
the capture source in question is the ALSA loopback device.
More information about the gstreamer-devel