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 580952 - [audioresample] bad quality/pops compared to plughw
[audioresample] bad quality/pops compared to plughw
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.22
Other Linux
: Normal normal
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-30 22:50 UTC by Justin Karneges
Modified: 2009-05-01 16:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Justin Karneges 2009-04-30 22:50:42 UTC
On my machine, this produces a tone as normal:

gst-launch-0.10 audiotestsrc ! 'audio/x-raw-int,rate=16000,width=16,channels=1' ! alsasink device=plughw:0,0

And this produces a tone full of pops:

gst-launch-0.10 audiotestsrc ! 'audio/x-raw-int,rate=16000,width=16,channels=1' ! audioconvert ! audioresample ! alsasink device=hw:0,0

The first command lets ALSA do the format conversion, and sounds good.  The second command uses audioconvert/audioresample to do the format conversion (which according to verbose output turns out to be 'audio/x-raw-int,rate=44100,width=32,channels=2'), and sounds bad.

This is also full of pops:

gst-launch-0.10 audiotestsrc ! 'audio/x-raw-int,rate=16000,width=16,channels=1' ! audioconvert ! audioresample ! 'audio/x-raw-int,rate=44100,width=32,channels=2' ! alsasink device=plughw:0,0

This third command shows that the problem is probably not an issue with hw vs plughw, but the mere use of audioconvert/audioresample.

I /think/ the bug is in audioresample.  Testing with legacyresample seems to make the pops go away.
Comment 1 Tim-Philipp Müller 2009-05-01 15:34:09 UTC
I can reproduce the problem of pops/crackling with a pipeline like the last one.

The patch from bug #580470 fixes this issue for me as well.
Comment 2 Jan Schmidt 2009-05-01 16:11:45 UTC
Ta, fixed:

commit 02a7b31f0e7a9e6630efe925696a9229423314aa
Author: Jan Schmidt <thaytan@noraisin.net>
Date:   Fri May 1 16:47:53 2009 +0100

    audioresample: Fix buffer size transformations
    
    When calculating the input/output buffer sizes in the transform_size functio
    take the number of channels into account, so we don't end up calculating
    a buffer size that only contains a partial number of audio frames.
    
    Also, when going from output size to input size, round down rather than
    up, so as to calculate the minimum number of samples that *might* yield
    a buffer of the intended destination size.
    
    Fixes: #580470 and #580952