GNOME Bugzilla – Bug 580952
[audioresample] bad quality/pops compared to plughw
Last modified: 2009-05-01 16:11:45 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.
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.
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