GNOME Bugzilla – Bug 660170
alsasrc: broken timestamps lead to alsasrc ! audiorate endless loop
Last modified: 2011-10-03 09:14:35 UTC
Using audiorate to smooth out the stream produced by alsasrc causes excessive CPU usage. On my machine, a Core i5 that has 2 cores and 4 hyperthreads, it uses more than 1 hyperthread. This pipeline trivially reproduces the problem: gst-launch alsasrc ! audiorate ! wavenc ! filesink location=/dev/null Redirecting the filesink location to an actual file shows that audiorate is producing an excessive number of samples (many thousands a second -- see the attached log also) and will produce a multi-gigabyte file within a minuite. Attached is a debug log generating by setting alsasrc and audiorate to debug logging levels.
In fact, the following simpler test-case also demonstrates the bug (and removes wavenc from consideration) gst-launch alsasrc ! audiorate ! filesink location=/dev/null
Created attachment 197512 [details] Log of `gst-launch --gst-debug-no-color --gst-debug=alsa:5,audiorate:5 alsasrc ! audiorate ! filesink location=/dev/null'
It's not excessive CPU usage, it's spinning in an almost-endless loop to insert samples between timestamp 0 and (almost) infinity, because alsasrc outputs broken timestamps: $ gst-launch-0.10 alsasrc ! identity ! queue ! fakesink -v 2>&1 | grep chain | head -n 2 3528 bytes, timestamp: 5124095:34:33.309596968, offset: 0, offset_end: 441 3528 bytes, timestamp: 5124095:34:33.309596968, offset: 18522, offset_end: 18963 ... no wonder... This got broken as part of commit 0b774e0b7cf7a8ef1780fb6100228ca6e8ca8bcf Author: Pontus Oldberg <pontus.oldberg@invector.se> Date: Mon May 9 11:50:05 2011 +0200 alsasrc: Improve timestamp accuracy Fixes bug #635256.
And indeed, I can confirm that reverting 0b774e0b7cf7a8ef178 fixes the problem.
Created attachment 197534 [details] [review] alsasrc: fail gracefully when ALSA does not give timestamps
Thanks Vincent. Your patch now makes the pipeline referenced above work normally. That is: gst-launch alsasrc ! audiorate ! filesink location=/dev/null works. But now this: gst-launch alsasrc device=hw:0,0 ! audiorate ! filesink location=/dev/null results in the following message: New clock: GstAudioSrcClock WARNING: from element /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: Can't record audio fast enough Additional debug info: gstbaseaudiosrc.c(840): gst_base_audio_src_create (): /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: Dropped 88576 samples. This is most likely because downstream can't keep up and is consuming samples too slowly. and directing the output to a file shows the original problem (too many samples too quickly). In other words, the problem remains even with your patch if the `device' parameter is used. Perhaps this is unrelated to the original problem that this bug was opened for? Thanks!
Created attachment 197553 [details] [review] alsasrc: fail gracefully when ALSA does not give timestamps
Indeed, for some unknown reason I get timestamps when using the device parameter, and these start at some large offset. So I've updated the patch to timestamp from the first offset we get from ALSA, if it gives one.
Vincent, I can confirm that your new patch works in all cases, with and without the `device' property. Looks like this fixes the bug Thanks!
commit c7282a5718c7f31f84fb31b2c38fab0f9a38e2b0 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Tue Sep 27 00:26:29 2011 +0100 alsasrc: fail gracefully when ALSA does not give timestamps https://bugzilla.gnome.org/show_bug.cgi?id=660170