GNOME Bugzilla – Bug 591625
[alsasrc] odd timestamping on start
Last modified: 2009-12-11 12:23:34 UTC
This doesn't look entirely right to me: $ gst-launch-0.10 alsasrc ! fakesink -v Setting pipeline to PAUSED ... /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: actual-buffer-time = 170521 /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: actual-latency-time = 21315 ... (width/depth=32,44100Hz,2ch) .. Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstAudioSrcClock ... ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315192, offset: 0, offset_end: 940 ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315193, offset: 940, offset_end: 1880 ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315193, offset: 1880, offset_end: 2820 ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315192, offset: 2820, offset_end: 3760 ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315193, offset: 3760, offset_end: 4700 ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315193, offset: 4700, offset_end: 5640 ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315193, offset: 5640, offset_end: 6580 ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315192, offset: 6580, offset_end: 7520 ... 7520 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.021315193, offset: 7520, offset_end: 8460 ... 7520 bytes, timestamp: 0:00:00.021179138, duration: 0:00:00.021315193, offset: 8460, offset_end: 9400 ... 7520 bytes, timestamp: 0:00:00.042494331, duration: 0:00:00.021315193, offset: 9400, offset_end: 10340 ... 7520 bytes, timestamp: 0:00:00.063809524, duration: 0:00:00.021315192, offset: 10340, offset_end: 11280 ... 7520 bytes, timestamp: 0:00:00.085124716, duration: 0:00:00.021315193, offset: 11280, offset_end: 12220 ... 7520 bytes, timestamp: 0:00:00.106439909, duration: 0:00:00.021315193, offset: 12220, offset_end: 13160
I can confirm this here, the problem is that the base time of alsasrc is ~170ms here and this will make baseaudiosrc clip the timestamps to 0 until the 170ms are read from the alsa device. (that's in line 994 of gstbaseaudiosrc.c) No idea why this happens :)
for me, pulseaudio seems to report a delay even before we read the first sample. Seems to work fine with alsa hw:0.
with the new slaving algorithm it seems to produce more normal values now.