Clock skewing algorithm

[Wim Taymans]

On 10/11/2011 03:15 PM, Tvrtko Ursulin wrote:
>
> Hi Wim, all,
>
> I was just talking with Jan Schmidt on #gstreamer about a curious clock
> skewing observation you might sched some light at.
>
> Essentially I am debugging AV sync issues when streaming video from v4l2src
> and audio from alsasrc. To narrow it down I went on to test purely audio
> pipeline in the form of "alsasrc ! audio/x-raw-int,rate=48000 ! queue min-
> threshold-time=2000000000 ! alsasink".

This pipeline is rather impossible to run, the queue will always overrun 
and block the source from producing more samples. You can see this with 
gst-launch with:

gstbaseaudiosrc.c(838): gst_base_audio_src_create (): 
/GstPipeline:pipeline0/GstAlsaSrc:alsasrc0:
Dropped 37920 samples. This is most likely because downstream can't keep 
up and is consuming samples too slowly.

The reason is that the default max size of the queue is 1 second and you 
ask it to buffer 2 seconds at least. You need to increase the 
max-size-time to something bigger than 2 seconds. We should make queue 
error on these invalid configurations..

It does not seem to cause and wrong skews here, though. Things just get 
choppy while the source drops samples and the sink consumes the 
occasional bursts of samples.

>
> What happens occasionally is that audio gets choppy and then stops completely.
> I have captured logs of one such incident, pulled out some information from
> clock skewing and plotted it with gnuplot for which I am attaching two plots.
>
> On the full plot you can see that after the second large skew spike average
> skew calculation seems to go wrong and starts oscillating between positive and
> negative values. On the zoomed in view you can see that there is no negative
> skew values, while average keeps oscillating. However on the first occurence of
> such large spike it seems to keep the average correct.
>
> Basically I have two question here. First is whether wrong average skew is
> expected to have negative effects on audio, including stopping completely, and
> then secondly whether it looks like a bug in average skew calculation which
> should be investigated deeper?

A wrong average skew could indeed mess up the timing.

Wim
>
> Regards,
>
> Tvrtko