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?