[pulseaudio-tickets] [PulseAudio] #358: Regression: overdriving/crackling

[PulseAudio]

#358: Regression: overdriving/crackling
-----------------------------------------+----------------------------------
 Reporter:  allquixotic                  |       Owner:  lennart
     Type:  defect                       |      Status:  new    
 Priority:  normal                       |   Milestone:         
Component:  daemon                       |    Severity:  major  
 Keywords:  crackling overdriven mixing  |  
-----------------------------------------+----------------------------------
 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.

-- 
Ticket URL: <http://pulseaudio.org/ticket/358>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server