GNOME Bugzilla – Bug 499181
audiorate inserting samples (due to rounding errors ?)
Last modified: 2009-10-22 12:36:02 UTC
audiorate is inserting one sample periodically, the following command : GST_DEBUG="audiorate*:5" gst-launch audiotestsrc ! audiorate ! fakesink 2>&1 | egrep "inserting" results to : 0:00:00.193252000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.261406000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.334504000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.403873000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.474330000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.539998000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.605779000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.674456000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.746070000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.818519000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples 0:00:00.888520000 25729 0x80d3478 DEBUG audiorate gstaudiorate.c:561:gst_audio_rate_chain:<audiorate0> inserting 1 samples These samples seems to be added due to round errors and does not seems to be necessary if round errors are not accumulated.
I think that it's a duplicate of this one: http://bugzilla.gnome.org/show_bug.cgi?id=363119
In this pipeline audioconvert is inserting 1 (2 bytes) sample when it does the following math to calculate the next_offset: /* Figure out the total accumulated segment time. */ run_time = in_time + audiorate->src_segment.accum; /* calculate the buffer offset */ in_offset = gst_util_uint64_scale_int (run_time, audiorate->rate, GST_SECOND); in_offset_end = in_offset + in_samples; In one of the cases I got from the logs I have: 10216780045(runtime) * 44100(rate) / 1000000000.0(GST_SECOND) = 450559.9999845, and of course it uses 450559. Should we be using gst_util_uint64_scale_round ?
Also, I can't reproduce it with alsasink, only with fakesink. This doesn't show the debug line about the samples: GST_DEBUG=audiorate:4 gst-launch audiotestsrc ! audiorate ! "audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)1" ! alsasink Replacing alsasink with fakesink shows it.
(In reply to comment #2) > > Should we be using gst_util_uint64_scale_round ? Yes, that would definitely improve the situation.
Fixed. commit 44d6ebc48f929cce52b3f187266ee9bf0327340c Author: Thiago Santos <thiagoss@embedded.ufcg.edu.br> Date: Thu Oct 22 08:40:01 2009 -0300 audiorate: be more accurate on offset math