Bogus timestamps produced by an audiosrc?

[Carlos Rafael Giani]

Hello,

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 
doesn't work.

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.

cheers