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 591625 - [alsasrc] odd timestamping on start
[alsasrc] odd timestamping on start
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.26
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-12 23:18 UTC by Tim-Philipp Müller
Modified: 2009-12-11 12:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2009-08-12 23:18:56 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
Comment 1 Sebastian Dröge (slomo) 2009-08-17 15:14:44 UTC
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 :)
Comment 2 Wim Taymans 2009-08-24 10:07:18 UTC
for me, pulseaudio seems to report a delay even before we read the first sample. Seems to work fine with alsa hw:0.
Comment 3 Wim Taymans 2009-12-11 12:23:34 UTC
with the new slaving algorithm it seems to produce more normal values now.