Bug 47830

Summary: Opening Gnome's Sound Settings can kill Pulseaudio
Product: PulseAudio Reporter: Tanu Kaskinen <tanuk>
Component: alsaAssignee: pulseaudio-bugs
Status: RESOLVED NOTOURBUG QA Contact: pulseaudio-bugs
Severity: major    
Priority: medium CC: lennart, neltnerb, sanjay.ankur
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Tanu Kaskinen 2012-03-24 23:31:42 UTC
When I opened Gnome's Sound Settings, Pulseaudio died after a short while. I had Pulseaudio running in gdb, so I have the log, but Pulseaudio was killed by the kernel so there's no backtrace. Here's the log, starting from gnome-control-center connecting:

I: [pulseaudio] client.c: Created 4 "Native client (UNIX socket client)"
D: [pulseaudio] protocol-dbus.c: Interface org.PulseAudio.Core1.Client added for object /org/pulseaudio/core1/client4
D: [pulseaudio] protocol-native.c: Protocol version: remote 26, local 26
I: [pulseaudio] protocol-native.c: Got credentials: uid=1000 gid=1000 success=1
D: [pulseaudio] protocol-native.c: SHM possible: yes
D: [pulseaudio] protocol-native.c: Negotiated SHM: yes
D: [pulseaudio] module-augment-properties.c: Looking for .desktop file for gnome-control-center
D: [pulseaudio] module-augment-properties.c: Found /usr/share/applications/gnome-control-center.desktop.
D: [pulseaudio] protocol-native.c: Client gnome-control-center changes mute of source alsa_input.pci-0000_00_1b.0.analog-stereo.
D: [pulseaudio] module-stream-restore.c: Not restoring device for stream source-output-by-application-id:org.gnome.VolumeControl, because already set
D: [pulseaudio] module-intended-roles.c: Not setting device for stream Peak detect, because already set.
I: [pulseaudio] source-output.c: Trying to change sample rate
I: [pulseaudio] source-output.c: Resampling enabled to 44100 Hz
I: [pulseaudio] module-stream-restore.c: Restoring mute state for source output source-output-by-application-id:org.gnome.VolumeControl.
D: [pulseaudio] source.c: Suspend cause of source alsa_input.pci-0000_00_1b.0.analog-stereo is 0x0000, resuming
D: [pulseaudio] reserve-wrap.c: Successfully acquired reservation lock on device 'Audio0'
I: [alsa-source] alsa-source.c: Trying resume...
I: [alsa-source] alsa-util.c: Trying to disable ALSA period wakeups, using timers only
D: [alsa-source] alsa-util.c: Maximum hw buffer size is 371 ms
[Thread 0x7fffe1e2f700 (LWP 26618) exited]
[Thread 0x7ffff7fad760 (LWP 26615) exited]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) 


I have tried reproducing this by opening and closing the sound settings for a few times, but no luck yet.
Comment 1 Tanu Kaskinen 2012-03-24 23:44:38 UTC
Here's a script for trying to reproduce:

while true ; do
        gnome-control-center sound &
        sleep 3s
        killall gnome-control-center
        sleep 6s
done
Comment 2 Arun Raghavan 2012-03-30 09:20:51 UTC
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.
Comment 3 Ankur Sinha (FranciscoD) 2012-04-17 12:48:26 UTC
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
Comment 4 Ankur Sinha (FranciscoD) 2012-04-17 13:17:59 UTC
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
Comment 5 Arun Raghavan 2012-04-17 20:59:39 UTC
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.
Comment 6 Arun Raghavan 2012-05-09 22:38:03 UTC
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.
Comment 7 Arun Raghavan 2012-05-11 07:28:01 UTC
(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.
Comment 8 Tanu Kaskinen 2012-05-30 20:30:19 UTC
*** Bug 50518 has been marked as a duplicate of this bug. ***
Comment 9 neltnerb@mit.edu 2012-05-30 20:37:27 UTC
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?
Comment 10 Tanu Kaskinen 2012-05-30 22:06:25 UTC
(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.
Comment 11 neltnerb@mit.edu 2012-05-31 17:03:22 UTC
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
Comment 12 Tanu Kaskinen 2012-05-31 21:50:09 UTC
(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.
Comment 13 neltnerb@mit.edu 2012-05-31 22:10:21 UTC
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?
Comment 14 Tanu Kaskinen 2012-05-31 22:42:56 UTC
(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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.