Here's a script for trying to reproduce:

while true ; do
        gnome-control-center sound &
        sleep 3s
        killall gnome-control-center
        sleep 6s
done

I can now reproduce this at will with:

  while /bin/true; do (audacity &) ; sleep 2s; killall audacity; done

This always causes the failure after a few seconds or within the order of a minute.

I've pinned this down to an ALSA HDA driver issue with David's help, and will figure out how to resolve this upstream.

I think I'm affected by this too:

*** pulseaudio -vvvv output ***
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] sink-input.c: Requesting rewind due to corking
D: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.pci-0000_00_1b.0.analog-stereo becomes idle, timeout in 5 seconds.
I: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.pci-0000_00_1b.0.analog-stereo idle for too long, suspending ...
D: [pulseaudio] sink.c: Suspend cause of sink alsa_output.pci-0000_00_1b.0.analog-stereo is 0x0004, suspending
I: [alsa-sink] alsa-sink.c: Device suspended...
I: [pulseaudio] core.c: All sinks and sources are suspended, vacuuming memory
D: [pulseaudio] reserve-wrap.c: Device lock status of reserve-monitor-wrapper@Audio0 changed: not busy
D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
D: [alsa-sink] sink-input.c: Requesting rewind due to uncorking
D: [pulseaudio] sink.c: Suspend cause of sink alsa_output.pci-0000_00_1b.0.analog-stereo is 0x0000, resuming
D: [pulseaudio] reserve-wrap.c: Successfully acquired reservation lock on device 'Audio0'
I: [alsa-sink] alsa-sink.c: Trying resume...
Killed

*** Attempted stack trace with gdb ***
Loaded symbols for /usr/lib64/pulse-1.1/modules/module-filter-apply.so
Reading symbols from
/usr/lib64/pulse-1.1/modules/module-dbus-protocol.so...Reading symbols from
/usr/lib/debug/usr/lib64/pulse-1.1/modules/module-dbus-protocol.so.debug...done.
done.
Loaded symbols for /usr/lib64/pulse-1.1/modules/module-dbus-protocol.so
0x000000343aee8f5f in ppoll (fds=<optimized out>, nfds=<optimized out>,
timeout=<optimized out>, sigmask=sigmask@entry=0x0) at
../sysdeps/unix/sysv/linux/ppoll.c:58
58                                     _NSIG / 8);
Missing separate debuginfos, use: debuginfo-install celt-0.11.1-3.fc17.x86_64
flac-1.2.1-9.fc17.x86_64 gsm-1.0.13-6.fc17.x86_64 libXau-1.0.6-3.fc17.x86_64
libXext-1.3.1-1.fc17.x86_64 libXi-1.6.0-1.fc17.x86_64
libgcc-4.7.0-2.fc17.x86_64 libogg-1.2.2-4.fc17.x86_64
libstdc++-4.7.0-2.fc17.x86_64 libuuid-2.21.1-1.fc17.x86_64
libvorbis-1.3.3-1.fc17.x86_64 nss-softokn-freebl-3.13.4-2.fc17.x86_64
(gdb) c
Continuing.
[Thread 0x7fa28ade6700 (LWP 22722) exited]
[Thread 0x7fa27ffa5700 (LWP 22732) exited]
[Thread 0x7fa291214780 (LWP 22721) exited]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) thread apply all bt full
(gdb) bt
No stack.
(gdb) thread apply all bt
(gdb)

*** Hardware info ***
[ankur@ankur dump]$ cat /proc/asound/cards
 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xfbe00000 irq 47
 1 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xfb080000 irq 16


[ankur@ankur dump]$ lspci | egrep -i audio
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High
Definition Audio (rev 06)
01:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev
a1)
[ankur@ankur dump]$

*** How I reproduce ***
[ankur@ankur ~]$ i=1; while true ; do  echo "iteration $i";  mpc  play;  sleep 1s;  mpc pause;   sleep 10s; (( i+=1 )) ; done

It consistently crashes by the 7th iteration.

Thanks,
Ankur

Hello,

I dug up further and added the following to /etc/modprobe.d/sound.conf:

options snd_hda_intel power_save=0

and I can't reproduce it any more (it just hit iteration 50). Can someone please check this out and confirm? It could just be a bug with the power management portion.

Thanks,
Ankur

My bug was in the Cirrus Logic-related bits of the HDA driver. I'll try to see if there's something similar in the NVidia bits too.

David posted a fix for this to alsa-devel:

http://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/051678.html

This should land in future kernel versions soon.

(In reply to comment #2)
> I can now reproduce this at will with:
> 
>   while /bin/true; do (audacity &) ; sleep 2s; killall audacity; done

Note that this also requires that module-suspend-on-idle be loaded with the timeout argument set to 0.

*** Bug 50518 has been marked as a duplicate of this bug. ***

Hi, I just discovered this bug (we hope) on my computer. Is there a straightforward workaround that I can implement until the kernel patch trickles through to debian testing?

Do I have to recompile the kernel to get this to stop being a problem? Man, I haven't had to do that in years =)

Is this bug also the cause of the strange static that appears on the SPDIF output which goes away when you mute and unmute the audio output? Or is that an unrelated issue?

(In reply to comment #9)
> Hi, I just discovered this bug (we hope) on my computer. Is there a
> straightforward workaround that I can implement until the kernel patch trickles
> through to debian testing?

At least I'm not aware of workarounds... or actually, if you remove or comment out the "load-module module-suspend-on-idle" line in /etc/pulse/default.pa, that might work (the alsa devices will be kept open all the time then). The problem may still occur when Pulseaudio starts.

> Do I have to recompile the kernel to get this to stop being a problem? Man, I
> haven't had to do that in years =)
> 
> Is this bug also the cause of the strange static that appears on the SPDIF
> output which goes away when you mute and unmute the audio output? Or is that an
> unrelated issue?

Sounds like an unrelated issue.

I think that I understand vaguely what this bug report is suggesting, but I'd like to verify my understanding because I don't know how to read patches very well.

To describe the behavior a bit further, I have configured my music player to entirely bypass pulseaudio and output directly to ALSA's iec958 device. This still causes the ALSA driver to crash, and now my music player also to crash.

Is this behavior consistent with the bug described here, or should I report it as a new bug to the ALSA team?

Best,
Brian

(In reply to comment #11)
> I think that I understand vaguely what this bug report is suggesting, but I'd
> like to verify my understanding because I don't know how to read patches very
> well.
> 
> To describe the behavior a bit further, I have configured my music player to
> entirely bypass pulseaudio and output directly to ALSA's iec958 device. This
> still causes the ALSA driver to crash, and now my music player also to crash.
> 
> Is this behavior consistent with the bug described here, or should I report it
> as a new bug to the ALSA team?

What does it mean for an alsa driver to crash? I understand "crashing" as sudden termination of a process, and the alsa driver is not a process.

Also, how does the music player crash? When starting it in a terminal, does the shell print "Killed" at the end of the console output? If it prints "Killed", then it sounds similar to what happens Pulseaudio, and it's then more likely be the same bug, but either way, I can't say anything certain.

What I mean is that I have to force reload the ALSA driver to re-enable sound. This doesn't necessarily terminate clementine (I am finding), but it does when it is playing music when I reload the drivers (less surprising).

Basically, is the pulseaudio bug here actually a bug in the ALSA driver? I just can't tell. And did the previous reporters experience this when using the SPDIF output, or more generally?

(In reply to comment #13)
> What I mean is that I have to force reload the ALSA driver to re-enable sound.
> This doesn't necessarily terminate clementine (I am finding), but it does when
> it is playing music when I reload the drivers (less surprising).
> 
> Basically, is the pulseaudio bug here actually a bug in the ALSA driver? I just
> can't tell. And did the previous reporters experience this when using the SPDIF
> output, or more generally?

I experienced it with the "normal" analog headphones output of my laptop. I don't know about others. I haven't heard of anyone needing to reload the sound card driver related to this bug.

This "Opening Gnome's Sound Settings can kill Pulseaudio" bug is an alsa bug, not a pulseaudio bug, which is why this is resolved as "notourbug". What you are describing is probably a different alsa bug, so it should be reported to the alsa developers.