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 552569 - audioresample producing strange sized buffers
audioresample producing strange sized buffers
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: 0.10.22
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-09-16 22:51 UTC by Håvard Graff (hgr)
Modified: 2008-11-28 10:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Håvard Graff (hgr) 2008-09-16 22:51:36 UTC
with the launch line:

gst-launch-0.10 audiotestsrc samplesperbuffer=960 num-buffers=3 ! "audio/x-raw-float, rate=(int)48000" ! audioresample ! "audio/x-raw-float, rate=(int)16000" ! fakesink -v

I get the output:

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* < ( 1268 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.019812500, offset: 0, offset_end: 317, flags: 32) 00CF2380"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* < ( 1284 bytes, timestamp: 0:00:00.019812500, duration: 0:00:00.020062500, offset: 317, offset_end: 638, flags: 0) 00CF2430"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* < ( 1280 bytes, timestamp: 0:00:00.039875000, duration: 0:00:00.020000000, offset: 638, offset_end: 958, flags: 0) 00CF24E0"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* < (   12 bytes, timestamp: 0:00:00.059875000, duration: 0:00:00.000187500, offset: 958, offset_end: 961, flags: 0) 00CF2538"

1268, 1284, 1280, (and 12) bytes.

In my opinion it should produce an even 1280 bytes every time. (960 * sizeof(float) * 16000 / 48000) as well as a even duration of 20ms. 

Fair enough that it uses a delayline, but this should be accounted for with inserting silence, making the first buffer 1280 bytes no matter what. 

And where does the extra 4 in 1284 come from? 

And is it really wanted behavior to have it output the few samples in the delayline(? I am guessing here) after you have sent an EOS? (we are talking 3 samples here, making it 187,5 microseconds of sound :)
Comment 1 Sebastian Dröge (slomo) 2008-11-28 10:41:00 UTC
The different sizes of buffers are intentional. The resampler internally uses a filter that adds some delay which results in the first buffer being a bit smaller and a small buffer being added at the end.
We don't insert zeroes in the beginning as we then either have a longer stream or would lose some audio data. GStreamer handles the added latency properly, even for live streams from an microphone for example ;)

The other part, the 3 added samples, are fixed in CVS with the new resampler. Also all buffers except the first and last have the same size now.