Description of problem:
When you play a single stream of audio, the sound is fine, no pop at start, everything sounds great. When a second stream starts, a loud crackle, pop, or other static sound is heard before the second stream plays. If you have two streams playing, a third does not exhibit this. I suspect it has something to do with the resample code, but I can't select a resample-method that makes it go away (although it seems to change the nature of the "pop")
I am using a Lenovo T61 which has the following sound card:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
Version-Release number of selected component (if applicable):
Start a long-running audio stream, then start a second one
Steps to Reproduce:
1. Start up rhythmbox, play an internet radio station or a song
2. run ogg123 -d pulse /usr/share/sounds/freedesktop/stereo/window-attention.oga
static or popping sound before window-attention plays
smooth addition of second stream to existing stream
I have been able to work around this by running:
cat /dev/zero | pacat -p &
If I have an audio stream running and also run this, I experience no popping from subsequent audio streams.
What happens different when a second stream starts vs a third? I don't know how PA works internally, but is the mixing code always active or does it only start when a second stream is added?
Hmm, this is probably an artifact of flat-volume induced volume change.
Could you please run "alsamixer -c0" and see if the volume sliders in that tool jump when you hear this artifact?
alsamixer -c0 does show a jump between '46' and '77' for the 'Master' channel, yes.
I added 'flat-volumes = no' to my /etc/pulse/daemon.conf and that seems to have fixed the problem, I do not see the jump and the 'pop' does not occur.
Is there a way to tweak the flat volume controls to prevent this, or is it because of the (admittedly cruddy) sound chip in the T61s?
Those pops you hear, is it possible that they simple are the much louder version of one of the streams? If so, this would be a duplicate of bug 525882.
Or are they unrelated static? If so this should be reassigned to the kernel so that the driver is fixed to not produce those artifacts when changing volume.
Please attach the output alsa-info.sh --no-upload generates.
When the second sound plays, I hear the first and second sound fine (and the status of pulseaudio only shows 2 sounds playing) but there is a crackling/popping sound for probably a couple hundredths of a second when the sound starts. The perceived volume doesn't change (which is why I never thought to look at the volume control). If it's another stream playing loudly, it's for a very very short time.
I tried to reproduce the pop by playing a single stream then adjusting the volume rapidly, but I can't seem to get it to happen. This very well may be a variation of #525882 and #518512
I am attaching my alsa-info.txt as well.
Created attachment 367603 [details]
alsa-info from a Lenovo T61p running rawhide i686
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
I am seeing something very similar to this, except I hear the pop when I go from zero streams to one stream.
My system has the same intel chipset (thinkpad X61).
When I look at alsamixer, however, I do not see any levels moving when I hear the pop.
I've noticed that the pop only occurs if zero streams have been playing for more than ten seconds.
play sound -> hear pop, then sound is fine
continue to play sounds with no pops
stop playing sounds
wait less than ten seconds, play another sound, no pop
stop playing sounds
wait ten seconds *hear another pop*
play sound, hear pop
It seems that the pop that I am hearing is linked to the suspend-on-idle module.
I commented out this line in /etc/pulse/default.pa
and I do not hear the pop anymore.
Paul, your issues is almost certainly related to a power management bug in your HDA hardware. There are already a couple of bugs open about that.
Richard, your issue looks as if it is an instance of bug 525882. Merging.
*** This bug has been marked as a duplicate of bug 525882 ***