Regression: overdriving/crackling

[allquixotic]

Defect appears in: PulseAudio version 0.9.12, and GIT as of 9/15 Defect is absent in: PulseAudio 0.9.11 and prior Architecture: x86 ALSA versions: 1.0.17a, 1.0.18rc3 (driver, lib, plugins) Distros: Mandriva cooker and Fedora 9 General Steps to Reproduce: 1. Find any two waveforms, where each waveform hits 0dB (maximum amplitude) at the same instant. For normalizing players (many music applications do this) it's very easy to coerce this behavior. 2. Play back two sounds at once through PulseAudio, using two instances of the same application or two different applications. If the application has software volume, turn it to the maximum. 3. Listen for clicks, pops or crackles. Empirical analysis indicates that each sample of the final mixed stream will sound overdriven (like shouting into a microphone with mic boost on) which may indicate that the sample's value is being overflowed. A bunch of samples which overflow like this in a short period of time sounds like crackling, as each individual one is a "pop".

Example Steps to Reproduce (requires gstreamer >= 0.10 and gstreamer-tools): 1. Execute the following commands together, at the same time (a script is easiest): gst-launch-0.10 filesrc location=/some/loud/file.mp3 ! decodebin2 ! pulsesink & gst-launch-0.10 filesrc location=/some/loud/file.mp3 ! decodebin2 ! pulsesink & 2. Observe the crackling effects.

Negative Test Case (proof of NO crackling when volumes are low): 1. Execute the following commands together, at the same time (a script is easiest): gst-launch-0.10 filesrc location=/some/loud/file.mp3 ! decodebin2 ! audioconvert ! volume volume=0.5 ! pulsesink & gst-launch-0.10 filesrc location=/some/loud/file.mp3 ! decodebin2 ! audioconvert ! volume volume=0.5 ! pulsesink & 2. Sound should be smooth; it may be loud, but no crackling.

Clients tested: 1. paplay 2. gst-launch and other gstreamer apps 3. Amarok2 and KDE event sounds -- phonon apps 4. Xine apps

Diagnosis from available evidence: 1. The problem IS in the daemon or client library, but not in third-party clients' use of PA. 2. The problem MAY be related to mixing math when using s16le samples as the native format of the mixing routines. When using float32ne, the effects of this issue are less noticeable. 3. The problem IS systemic; it has been confirmed by Colin Guthrie using Mandriva and another fellow on IRC who was using Fedora 9 and built PA 0.9.12 from source. 4. The problem IS specific to 0.9.12, and no prior versions. 5. The problem IS NOT specific to using time-based scheduling; with time-based scheduling disabled, the problem manifests the same. 6. The problem IS NOT applicable to streams which remain at low volumes. 7. The problem MAY be specific to snd-hda-intel hardware; up to this point, I have not heard of a case where this bug has been confirmed on other hardware. Then again, I have not heard anything in the negative either. This could use some more testing.

Only a few people are knowledgeable enough about the core mixing code to mess around in there; I may do some experimentation myself, but I expect Colin, Lennart or Pierre would be most suitable to address this bug properly.

[coling]

(Reformatting description to be Trac-friendly :))

• Defect appears in: PulseAudio version 0.9.12, and GIT as of 9/15
• Defect is absent in: PulseAudio 0.9.11 and prior
• Architecture: x86
• ALSA versions: 1.0.17a, 1.0.18rc3 (driver, lib, plugins)
• Distros: Mandriva cooker and Fedora 9

General Steps to Reproduce

1. Find any two waveforms, where each waveform hits 0dB (maximum amplitude) at the same instant. For normalizing players (many music applications do this) it's very easy to coerce this behavior.
2. Play back two sounds at once through PulseAudio, using two instances of the same application or two different applications. If the application has software volume, turn it to the maximum.
3. Listen for clicks, pops or crackles. Empirical analysis indicates that each sample of the final mixed stream will sound overdriven (like shouting into a microphone with mic boost on) which may indicate that the sample's value is being overflowed. A bunch of samples which overflow like this in a short period of time sounds like crackling, as each individual one is a "pop".

Example Steps to Reproduce

(requires gstreamer >= 0.10 and gstreamer-tools):

1. Execute the following commands together, at the same time (a script is easiest):

   gst-launch-0.10 filesrc location=/some/loud/file.mp3 \
    ! decodebin2 ! pulsesink &
   

   gst-launch-0.10 filesrc location=/some/loud/file.mp3 \
    ! decodebin2 ! pulsesink &
   

2. Observe the crackling effects.

Negative Test Case (proof of NO crackling when volumes are low)

1. Execute the following commands together, at the same time (a script is easiest):

   gst-launch-0.10 filesrc location=/some/loud/file.mp3 \
    ! decodebin2 ! audioconvert ! volume volume=0.5 ! pulsesink &
   

   gst-launch-0.10 filesrc location=/some/loud/file.mp3 \
    ! decodebin2 ! audioconvert ! volume volume=0.5 ! pulsesink &
   

2. Sound should be smooth; it may be loud, but no crackling.

Clients tested

1. paplay
2. gst-launch and other gstreamer apps
3. Amarok2 and KDE event sounds -- phonon apps
4. Xine apps

Diagnosis from available evidence

1. The problem IS in the daemon or client library, but not in third-party clients' use of PA.
2. The problem MAY be related to mixing math when using s16le samples as the native format of the mixing routines. When using float32ne, the effects of this issue are less noticeable.
3. The problem IS systemic; it has been confirmed by Colin Guthrie using Mandriva and another fellow on IRC who was using Fedora 9 and built PA 0.9.12 from source.
4. The problem IS specific to 0.9.12, and no prior versions.
5. The problem IS NOT specific to using time-based scheduling; with time-based scheduling disabled, the problem manifests the same.
6. The problem IS NOT applicable to streams which remain at low volumes.
7. The problem MAY be specific to snd-hda-intel hardware; up to this point, I have not heard of a case where this bug has been confirmed on other hardware. Then again, I have not heard anything in the negative either. This could use some more testing.

Only a few people are knowledgeable enough about the core mixing code to mess around in there; I may do some experimentation myself, but I expect Colin, Lennart or Pierre would be most suitable to address this bug properly.

[coling]

Just to add my comments now:

1. For reference, Mandriva cooker is only testing the 0.9.12 version but that doesn't detract from the tests/results in any way!
2. Thanks for the vote of confidence but I seriously doubt I know enough about the core or resampling or even sound in general to be able to address this bug!! I can poke and fiddle about but anything complex and I bow out to Lennart or other less amateur players! :)

[lennart]

I am not sure I fully understand this bug report, but if I am right then you are complaining that if PA mixes two streams that use the full sample range we employ saturated summing?

At this point PA does not do DRC when mixing. It would be good if we did, but we don't.

[allquixotic]

Hi Lennart,

I have used hardware DRC equipment before and agree that implementing such an algorithm in software would be a robust solution to this problem. However, I was just comparing the effects of saturation in 0.9.12 to how it was in previous versions of PA. With s16le, saturation distortion is *much* worse with 0.9.12 than previously.

Anyway, setting the default-sample-format to float32ne makes this bug go away.

Those wishing to ship 0.9.12 in a distro might consider setting default-sample-format = float32ne in the daemon.conf file! Otherwise your users will complain that mixing two loudish sounds causes crackling, and the whole process of discovering this bug will start over again.

Cynically marking this as invalid in anticipation of DRC not sneaking its way into PA for ages and ages :)

[lennart]

Actually you were right before, this was a regression from 0.9.10. And I believe I fixed it now with rea82dec.