Comment 43 for bug 116990

Could someone reproducing the bug please compare (or attach) the output of:
LC_ALL=C gst-launch -v filesrc location=xyz.ogg ! decodebin ! audioconvert ! audioresample ! alsasink
and:
LC_ALL=C gst-launch -v filesrc location=xyz.ogg ! decodebin ! audioconvert ! audioresample ! volume volume=1.0 ! alsasink
(note -v flag)

as I wonder whether different caps are negociated in the two cases. The first pipeline should produce the problematic sound and the second shouldn't.

In my case -- I don't get the crackling sound -- I see the second pipeline negociated with 32-bits audio samples instead of 16-bits on the whole pipeline:
-/pipeline0/audioconvert0.src: caps = audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)44100, channels=(int)2
+/pipeline0/audioconvert0.src: caps = audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2
...

I guess this could be a GStreamer or Alsa issue for specific sample sizes; this is also suggested by the indication that using "pulsesink" instead of alsa seems to help some persons.

If you see a difference, then please try replacing "volume volume=1.0" in the second pipe line with:
'audio/x-raw-int,endianness=(int)1234,signed=(boolean)true,width=(int)16,depth=(int)16,rate=(int)44100,channels=(int)2'
(mind the quotes as otherwise your shell might be unhappy)

if it doesn't crack with neither volume volume=1.0 or the above caps filter, then it's likely specific to the output mode and it would be useful to check with alsa output directly instead of GStreamer.