[pulseaudio-discuss] Bad Crackling with PA 0.9.12

[Sean McNamara]

I'm still getting this with the latest development snapshots of
alsa-driver, alsa-lib, alsa-plugins and pulseaudio. Can't seem to
figure it out except that I think the mixing math has been changed to
"add" the amplitudes of the two sounds even if they ultimately end up
overdriving.

Here's a very simple contrived test:

1. Run `gst-launch-0.10 audiotestsrc wave=sine ! audioconvert ! volume
volume=0.2 ! pulsesink &` several times (2 or 3 of them stacked).
Notice, no distortion.
2. Kill all of those, and run `gst-launch-0.10 audiotestsrc wave=sine
! audioconvert ! pulsesink &` (volume element removed) twice. BZZZT!
May want to remove headphones from ears for this one - painful.
3. Kill pulseaudio and other audio-using apps, then run
`gst-launch-0.10 audiotestsrc wave=sine ! audioconvert ! alsasink
device=plug:dmix:0 &` twice. No bzzt! You have to run it *three* times
with the volume at 0dB to get it to overdrive, probably because dmix
uses saturation.

A more real-world test would be to turn down your volume in Rhythmbox
to about 25% then play Pidgin IM beeps. No ugly clicks or crackling.
Turn Rhythmbox back up to 100% and every single IM beep crackles
badly. This only works if your music is sufficiently loud; 100% of a
track that is very quiet won't make the effect as noticeable.

Things I've ruled out that this is NOT related to:
-Not specific to libspeex; behavior is the same using the
libsamplerate resampler.
-Not specific to temporal scheduling; I passed tsched=0, disabled
m-hal-detect and m-detect, and still the same problem.
-Not specific to ALSA 1.0.17; or at least it has yet to be fixed in
the latest ALSA GIT if it's indeed an ALSA problem.
-Not specific to only higher quality resamplers; tried speex-float-1
and src-sinc-best-quality and speex-float-9; same issues.
-Not specific to floating point resamplers; tried speex-fixed-N; same issues.

However, I have a very interesting result from a test of using the
`float32ne` default sample format of the server: only the BZZZT!! of
gst-launch is now observable using this sample format. Ordinary sounds
(like the Rhythmbox-Pidgin case described above) work just fine.

So what's going on? It seems like using signed 16-bit samples for the
mixing is causing the overdriving/crackling. 32-bit float samples,
while more CPU-intensive, jive much better.

Open Question: is it specific to snd-hda-intel? Anyone test this on
other hardware to attempt to reproduce it?

I'm not sure if float32ne is the ultimate fix to this problem, but it
certainly seems to address it as a workaround. Instead of this
problem, I now face dropouts (because of high CPU load?) and the
positional event sounds are distorted :)

Thanks,

Sean


On Fri, Sep 12, 2008 at 2:52 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Sean McNamara wrote:
>> I'm running Mandriva 2009.0 RC1 with PA 0.9.12 (from the tarball) that
>> I compiled myself. Right now my worst problem with 0.9.12 is severe
>> (loud!) crackling whenever multiple streams are active at once.
>
> For your convenience and ease of testing there is an RPM for 0.9.12 in
> the cooker main/testing repo (has been there for yonks!)
>
>> I am using alsa kernel and lib 1.0.18rc3; previously I tried ALSA
>> 1.0.17 with the same exact results. You might also be pleased to know
>> that I am stubbornly using one of those pesky and oft-broken
>> snd-hda-intel cards! :)
>>
>> Here's a simple way to reproduce the issue:
>>
>> $ for (( i = 0; i < 2; i++ )); do
>> #Pick a wav file that exists on your system
>> paplay /usr/share/sounds/shutdown.wav &
>> done
>>
>> In 0.9.10 and prior, this would play the same sound file twice on top
>> of itself in very rapid succession, which would make it sound pretty
>> loud, but there wouldn't be horrible crackling. With 0.9.12, it sounds
>> like the loudness of each sound is combined, creating an amplification
>> that is _way_ overdriven, and hence the distortion. This occurs much
>> more noticeably in wav files that are normalized to 0dB, meaning that
>> the loudest parts of the file are set at 0dB. For very quiet sounds
>> whose internal structure consistently maintains a relatively low
>> volume, this effect is almost invisible.
>>
>> Being normalized to 0dB has never been a condition causing this to
>> occur before; previous versions of pulse could play the same wave
>> files just fine without overdriving. Have the maths for
>> resampling/mixing changed now? And is this intended or accidental?
>>
>> My config files are pasted: http://rafb.net/p/jW16b668.html and
>> http://rafb.net/p/cUUFj679.html
>
> I'm also seeing some degree of crackling too, but not specifically when
> playing multiple streams.
>
> To be honest, I think 0.9.12 is actually slightly worse than the last
> snapshot I built, but I can put my finger on it. The only change I can
> think of of late is one relating to a
> snd_pcm_hw_params_set_periods_near() call, but I've not looked hard at
> the code/changelog to see if there is some other thing that could be
> causing it.
>
> That said, I've been getting this slight crackling ever since 0.9.11 but
> I've not had time to fully discuss this with Lennart yet... (always
> seems to be something more important to discuss!)
>
> Oh and I'm also on hda! ;)
>
> Col
>
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>   Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>   Mandriva Linux Contributor [http://www.mandriva.com/]
>   PulseAudio Hacker [http://www.pulseaudio.org/]
>   Trac Hacker [http://trac.edgewall.org/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>