In a pipeline where gstalsasrc provides the pipeline clock, time spent in buffer overruns is missing.

In such a pipline, the pipeline clock is provided by gst_audio_base_src_get_time which does not increase during overruns. The buffer timestamps are set in gst_audio_base_src_create and do not take into account buffer overruns.

This causes problems in pipelines which have live sinks where this is detected as clock skew (https://bugzilla.gnome.org/show_bug.cgi?id=692953).

When working around this by setting provide-clock=false on alsasink this triggers alsasrc to add buffer timestamps. (http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=a049b102da7c1b68a31c49717a4b37b351ea4b34). In this case, overruns are visible in the buffer timestamps but the difference in clock (alsa vs pipeline) is not compensated.

So either buffer overruns are not visible (alsasrc provides clock) or buffer timestamps are not matched against the pipeline clock (alsasrc doesn't provide the clock).

Do do it properly the alsasrc should provide a clock which takes into account buffer overrun and use that clock to timestamp the buffers.
If the pipeline uses another (monotonic) clock, the alsa timestamps should be reconverted to that clock.

Some simple changes can be made:
Perhaps alsasrc should not provide a clock by default?
For most if not all audio cards, the current code works fine when the pipeline clock is the monotonic OS clock. This is because snd_pcm_status_get_htstamp equals the clock time. If the call to the first in gstalsasrc was replaced by a call to the latter, it will even work fine for all monotonic system clocks.