[gstreamer-bugs] [Bug 581460] [baseaudiosrc] Reusing audio source leads to null timestamps on first buffers

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=581460

  GStreamer | gst-plugins-base | Ver: git




------- Comment #4 from René Stadler  2009-05-05 13:09 UTC -------
Some log excerpts and analysis (egrep 'identity|EOS|buffer timestamp|processed
samples' debug.log):

processed samples: raw 0, delay 0, real 0, time 0:00:00.000000000
buffer timestamp 0, ts 0:00:00.000000000 <= base_time 0:00:00.000000000
processed samples: raw 441, delay 49, real 490, time 0:00:00.011111111
buffer timestamp 0:00:00.010000000 (base_time 0:00:00.000000000)
buffer timestamp 0:00:00.020000000 (base_time 0:00:00.000000000)
buffer timestamp 0:00:00.030000000 (base_time 0:00:00.000000000)
buffer timestamp 0:00:00.040000000 (base_time 0:00:00.000000000)
buffer timestamp 0:00:00.050000000 (base_time 0:00:00.000000000)
[...]

and so on until

[...]
buffer timestamp 0:00:00.960000000 (base_time 0:00:00.000000000)
buffer timestamp 0:00:00.970000000 (base_time 0:00:00.000000000)
buffer timestamp 0:00:00.980000000 (base_time 0:00:00.000000000)
buffer timestamp 0:00:00.990000000 (base_time 0:00:00.000000000)
Got EOS

Makes sense, 10ms per buffer (latency-time), num-buffers=100 makes this the
last buffer, spanning to 1s with its 10ms duration. Now state change cycle and
the second round (with the faulty timestamps):

processed samples: raw 44100, delay 0, real 44100, time 0:00:01.000000000
processed samples: raw 44541, delay 0, real 44541, time 0:00:01.010000000
buffer timestamp 0, ts 0:00:00.820000000 <= base_time 0:00:01.010000000
processed samples: raw 44541, delay 103, real 44644, time 0:00:01.012335600
buffer timestamp 0, ts 0:00:00.830000000 <= base_time 0:00:01.010000000
Buffer not time-contiguous with previous one: prev ts 0:00:00.000000000, prev
dur 0:00:00.010000000, new ts 0:00:00.000000000 (expected ts 0:00:00.010000000,
delta=-0:00:00.010000000)
buffer timestamp 0, ts 0:00:00.840000000 <= base_time 0:00:01.010000000
Buffer not time-contiguous with previous one: prev ts 0:00:00.000000000, prev
dur 0:00:00.010000000, new ts 0:00:00.000000000 (expected ts 0:00:00.010000000,
delta=-0:00:00.010000000)
buffer timestamp 0, ts 0:00:00.850000000 <= base_time 0:00:01.010000000
Buffer not time-contiguous with previous one: prev ts 0:00:00.000000000, prev
dur 0:00:00.010000000, new ts 0:00:00.000000000 (expected ts 0:00:00.010000000,
delta=-0:00:00.010000000)
[...]

and so on until the internal timestamps reach up to the base_time:

[...]
Buffer not time-contiguous with previous one: prev ts 0:00:00.000000000, prev
dur 0:00:00.010000000, new ts 0:00:00.000000000 (expected ts 0:00:00.010000000,
delta=-0:00:00.010000000)
buffer timestamp 0, ts 0:00:01.010000000 <= base_time 0:00:01.010000000
Buffer not time-contiguous with previous one: prev ts 0:00:00.000000000, prev
dur 0:00:00.010000000, new ts 0:00:00.000000000 (expected ts 0:00:00.010000000,
delta=-0:00:00.010000000)
buffer timestamp 0:00:00.010000000 (base_time 0:00:01.010000000)
buffer timestamp 0:00:00.020000000 (base_time 0:00:01.010000000)
buffer timestamp 0:00:00.030000000 (base_time 0:00:01.010000000)
buffer timestamp 0:00:00.040000000 (base_time 0:00:01.010000000)
buffer timestamp 0:00:00.050000000 (base_time 0:00:01.010000000)
[...]
buffer timestamp 0:00:00.790000000 (base_time 0:00:01.010000000)
buffer timestamp 0:00:00.800000000 (base_time 0:00:01.010000000)
Got EOS
processed samples: raw 80262, delay 0, real 80262, time 0:00:01.820000000


Other observations:

pulsesrc sees these warning after each EOS:
0:00:01.875599121 13816 0xb2000478 WARN              audiosrc
gstaudiosrc.c:228:audioringbuffer_thread_func:<pulsesrc0> error reading data
(reason: Success), skipping segment

alsasrc does not produce this warning, but the outcome is the same except that
the numbers are different.

Also, increasing the latency-time property lowers the number of null
timestamped buffers.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=581460.