After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 699744 - alsasrc: timestamps provided by audiosrc subclass not used when running under slave clock
alsasrc: timestamps provided by audiosrc subclass not used when running under...
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal normal
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-05-06 09:50 UTC by Alexander Schrab
Modified: 2013-05-20 09:26 UTC
See Also:
GNOME target: ---
GNOME version: ---

Make driver timestamps work (1.42 KB, patch)
2013-05-07 05:56 UTC, Alexander Schrab
none Details | Review
use gst_element_get_clock (2.26 KB, patch)
2013-05-20 08:49 UTC, Alexander Schrab
none Details | Review
Patch #3 (2.34 KB, patch)
2013-05-20 09:21 UTC, Alexander Schrab
committed Details | Review

Description Alexander Schrab 2013-05-06 09:50:03 UTC
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?
Comment 1 Alexander Schrab 2013-05-07 05:56:12 UTC
Created attachment 243453 [details] [review]
Make driver timestamps work

This patch works for me, but I must say I am not sure it's entirely correct. Someone with deeper knowledge of how the clocks are meant to work for alsa needs to take a closer look.

This patch fixes two issues:

* check the pipeline clock, not the clock in audiobasesrc for systemclock/monotonic
* use the provided timestamp even if we are slaved under another clock.
Comment 2 Alexander Schrab 2013-05-17 11:55:37 UTC
Could anyone take a look at this? Would be really good to get some progress on this...
Comment 3 Sebastian Dröge (slomo) 2013-05-17 12:07:55 UTC
I think this is correct, but would like Wim to comment on it. It's also how I solved the same problem for myself in the end before seeing this bug :)
Comment 4 Alexander Schrab 2013-05-20 08:49:53 UTC
Created attachment 244760 [details] [review]
use gst_element_get_clock
Comment 5 Alexander Schrab 2013-05-20 09:21:15 UTC
Created attachment 244762 [details] [review]
Patch #3

check for null clock
Comment 6 Sebastian Dröge (slomo) 2013-05-20 09:25:59 UTC
commit a049b102da7c1b68a31c49717a4b37b351ea4b34
Author: Alexander Schrab <>
Date:   Tue May 7 07:49:00 2013 +0200

    alsasrc: Make using driver timestamps possible