Description of problem: When I resume from suspend all sound applications block on the sound device until I switch VTs. Version-Release number of selected component (if applicable): pulseaudio-0.9.10-1.fc9.i386 How reproducible: every time Steps to Reproduce: 1. Start Rhythmbox 2. Play song 3. Suspend computer 4. Resume computer Actual results: Rhythmbox is not playing. Once I switch VTs away and back it resumes playing. It looks like the contents of /var/run/hald/acl-list is in sync with what getfacl says for each of the listed devices.
And the obvious question (especially given who's reporting it :-), ConsoleKit thinks that your session is active, right? Since we do some chvt'ing during the suspend/resume process
:) Yep ConsoleKit has it marked as active.
Hmm, it looks like a bug in your sound driver: it isn't capable of resuming properly after a suspend. Could you please run PA in a terminal with -vv, then suspend and resume and paste the output here? (You should run pulseaudio -k first, to make sure PA is stopped before you start it with -vv)
Created attachment 304388 [details] Log from pa: start rb,suspend,resume This log includes is from the following actions: 1. pa -vv 2. start rhythmbox 3. start playback 4. suspend computer 5. resume computer (playback doesn't resume)
Created attachment 304389 [details] Log from pa: when switching vts after a resume This is from the same instance of pa that produced the previous log output. The only thing that is happening at this time is: 1. Switch VT from 7 to 6 using hotkeys 2. Switch VT from 6 to 7 using hotkeys
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I see exactly this problem with F-9. ]# rpm -qa | grep pulse pulseaudio-module-gconf-0.9.10-1.fc9.x86_64 gstreamer-plugins-pulse-0.9.5-0.5.svn20070924.fc9.x86_64 pulseaudio-0.9.10-1.fc9.x86_64 alsa-plugins-pulseaudio-1.0.16-4.fc9.x86_64 pulseaudio-utils-0.9.10-1.fc9.x86_64 pulseaudio-libs-glib2-0.9.10-1.fc9.x86_64 pulseaudio-core-libs-0.9.10-1.fc9.x86_64 pulseaudio-libs-0.9.10-1.fc9.x86_64 pulseaudio-module-x11-0.9.10-1.fc9.x86_64 pulseaudio-libs-0.9.10-1.fc9.i386 pulseaudio-esound-compat-0.9.10-1.fc9.x86_64 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01d7 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 21 Region 0: Memory at efebc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Virtual Channel <?> Capabilities: [130] Root Complex Link <?> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel
Lennart - any further thoughts on this? If you still think it's a driver problem, should the bug not be reassigned to the kernel maintainers?
Hmm, yes, this probably needs to be reassigned to the kernel. I am pretty sure it's the ALSA driver that doesn't reinitialize the audio device for playback correctly after coming back from suspend. The VT switch and back will cause PA to reopen the audio device which fixes the issue because the ALSA driver is reinitialized due to reopening.
Hmm, looks like I have the same problem, but I've been reporting to the wrong bug (# 443322)
Me too. Same problem. Fedora 10 current. No sound after resume. rmmod the sound card module, loading the module back, and restarting pulseaudio does not fix the problem. My user is in pulse-rt group. I removed the .pulse-cookie file, confirmed that I owned /tmp/pulse-$whatever, etc. Linux lt1.MY-DOMAIN-REMOVED 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux [root@lt1 tmp]# rpm -qa | grep pulse pulseaudio-module-x11-0.9.13-6.fc10.i386 pulseaudio-libs-0.9.13-6.fc10.i386 pulseaudio-0.9.13-6.fc10.i386 pulseaudio-core-libs-0.9.13-6.fc10.i386 pulseaudio-utils-0.9.13-6.fc10.i386 pulseaudio-libs-glib2-0.9.13-6.fc10.i386 plymouth-plugin-pulser-0.6.0-0.2008.11.17.3.fc10.i386 xine-lib-pulseaudio-1.1.15-3.fc10.i386 kde-settings-pulseaudio-4.1-4.20081031svn.fc10.noarch alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386 [root@lt1 tmp]# lsmod | grep snd snd_hda_intel 351124 3 snd_seq_dummy 6660 0 snd_seq_oss 30364 0 snd_seq_midi_event 9600 1 snd_seq_oss snd_seq 48576 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 10124 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 42496 0 snd_mixer_oss 16896 1 snd_pcm_oss snd_pcm 65924 2 snd_hda_intel,snd_pcm_oss snd_timer 22024 2 snd_seq,snd_pcm snd_page_alloc 11016 2 snd_hda_intel,snd_pcm snd_hwdep 10500 1 snd_hda_intel snd 50616 16 snd_hda_intel,snd_seq_dummy,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep soundcore 9416 1 snd
I resolved my issue by adding a configuration file within /etc/modprobe.d and rebooting. I created the file /etc/modprobe.d/sound I put this line into that file: options snd-hda-intel model=acer This computer is an Acer Aspire One netbook -- the version that shipped originally with Windows XP, which is slightly different than the one that ships with Linux. Adding this modprobe option seems to fix the problem with sound not functioning after resuming from suspend. Changing this option changes mixer settings. You may need to make adjustments to your mixer settings after making this change. Supposedly, there will be a different modprobe option to address this in the future. "...an option model=acer-aspire especially for the Acer Aspire One. This will be included in kernel >=2.6.28. If you want to use it while still having a 2.6.27 kernel..." [ from http://wiki.archlinux.org/index.php/Acer_Aspire_One ] This seems to be a fairly common issue. There is a bugzilla report [ https://bugzilla.redhat.com/show_bug.cgi?id=463926 ] of the same issue on a dell that required model=dell to work properly. There should be a way to avoid this problem _or_ to make finding the resolution simpler. Any ideas?
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Changin Fedora release as I see something similar in Fedora 10 as well.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still seeing this in F-11, so am moving it to that version.
I also have this problem on F11, LXDE remix (using gnome-openbox desktop) on an ibm thinkpad 600x, so using the model=acer work-around obviously isn't going to fix it. I'll keep looking around.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.