Description of problem: Sound usually works fine om my Dell optiplex 745 with /etc/modprobe.conf: alias snd-card-0 snd-hda-intel options snd-card-0 index=0 options snd-hda-intel index=0 lsmod|grep snd snd_hda_intel 274529 2 snd_seq_dummy 6725 0 snd_seq_oss 29889 0 snd_seq_midi_event 9793 1 snd_seq_oss snd_seq 44849 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 10061 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 37569 0 snd_mixer_oss 16705 2 snd_pcm_oss snd_pcm 63685 2 snd_hda_intel,snd_pcm_oss snd_timer 20549 2 snd_seq,snd_pcm snd_page_alloc 11337 2 snd_hda_intel,snd_pcm snd_hwdep 10309 1 snd_hda_intel snd 43461 11 snd_hda_intel,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep soundcore 9633 2 snd But after suspend/resume it might work partially, but then it stops working in rhythmbox, flash, mplayer, vlc. Commandline vlc and mplayer reports the samme error: [AO_ALSA] alsa-lib: confmisc.c:768:(parse_card) cannot find card '0' [AO_ALSA] alsa-lib: conf.c:3510:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device [AO_ALSA] alsa-lib: confmisc.c:392:(snd_func_concat) error evaluating strings [AO_ALSA] alsa-lib: conf.c:3510:(_snd_config_evaluate) function snd_func_concat returned error: No such device [AO_ALSA] alsa-lib: confmisc.c:1251:(snd_func_refer) error evaluating name [AO_ALSA] alsa-lib: conf.c:3510:(_snd_config_evaluate) function snd_func_refer returned error: No such device [AO_ALSA] alsa-lib: conf.c:3982:(snd_config_expand) Evaluate error: No such device [AO_ALSA] alsa-lib: pcm.c:2145:(snd_pcm_open_noupdate) Unknown PCM default [AO_ALSA] Playback open error: No such device Version-Release number of selected component (if applicable): kernel-2.6.23.1-49.fc8 alsa-lib-1.0.15-1.fc8 Additional info: It might be a kernel/suspend bug instead of an alsa bug. I think it used to work better with the latest F7 updates.
Can you please attach output of "ll /dev/snd/" when sound doesn't work? If files there are owned by root it's a bug somewhere in udev/console kit...
I just had a similar problem where sound didn't work and mplayer also gave en error (but another that I didn't catch). But that was after a reboot and without suspend/restore. Previously I had seen a pattern that lead me to think it was related to suspend - now I don't know... But this time I closed firefox (with flash) and rhythmbox, restarted nasd, started firefox and rhythmbox again, and then everything worked. But I did it all at once and didn't get the problem/solution/workaround nailed down. Mext time I will try to narrow it down - and check /dev/snd/ .
Got the original problem again. Had just booted the machine, suspended and resumed, started firefox on flash page at http://www.club-internet.fr/le-duel/ , started rhythmbox, and it couldn't play oggs. mplayer reports the same alsa-lib messages as above. [root@localhost ~]# ll /dev/snd/ total 0 crw-rw----+ 1 root root 116, 8 2007-11-28 11:04 controlC0 crw-rw----+ 1 root root 116, 7 2007-11-28 11:04 hwC0D0 crw-rw----+ 1 root root 116, 6 2007-11-28 11:04 pcmC0D0c crw-rw----+ 1 root root 116, 5 2007-11-28 11:04 pcmC0D0p crw-rw----+ 1 root root 116, 4 2007-11-28 11:04 pcmC0D1p crw-rw----+ 1 root root 116, 3 2007-11-28 11:04 seq crw-rw----+ 1 root root 116, 2 2007-11-28 11:04 timer [root@localhost ~]# I tried restarting firefox, rhythmbox and nasd - that changed nothing. I tried a hack-workaround chmod a+rw /dev/snd/* and then mplayer and firefox flash worked again. Rhythmbox still didn't work and locked badly. mplayer then fails with [AO_ALSA] alsa-lib: pcm_hw.c:1099:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Device or resource busy [AO_ALSA] alsa-lib: pcm_dmix.c:866:(snd_pcm_dmix_open) unable to open slave [AO_ALSA] Playback open error: Device or resource busy Could not open/initialize audio device -> no sound. [root@localhost ~]# lsof /dev/snd/pcmC0D0p COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME exe 2746 mk mem CHR 116,5 3453 /dev/snd/pcmC0D0p exe 2746 mk 45u CHR 116,5 3453 /dev/snd/pcmC0D0p [root@localhost ~]# ps -fed|grep 2746 mk 2746 2626 0 11:04 ? 00:00:10 /usr/bin/pulseaudio --log-target=syslog
But ... after a reboot and with sound working I get the same ll output: [root@localhost ~]# ll /dev/snd/ total 0 crw-rw----+ 1 root root 116, 8 2007-11-28 12:50 controlC0 crw-rw----+ 1 root root 116, 7 2007-11-28 12:50 hwC0D0 crw-rw----+ 1 root root 116, 6 2007-11-28 12:50 pcmC0D0c crw-rw----+ 1 root root 116, 5 2007-11-28 12:50 pcmC0D0p crw-rw----+ 1 root root 116, 4 2007-11-28 12:50 pcmC0D1p crw-rw----+ 1 root root 116, 3 2007-11-28 12:50 seq crw-rw----+ 1 root root 116, 2 2007-11-28 12:50 timer [root@localhost ~]# lsof /dev/snd/* COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME exe 2600 mk mem CHR 116,5 3455 /dev/snd/pcmC0D0p exe 2600 mk 15u CHR 116,8 3474 /dev/snd/controlC0 exe 2600 mk 21u CHR 116,8 3474 /dev/snd/controlC0 exe 2600 mk 26u CHR 116,5 3455 /dev/snd/pcmC0D0p mixer_app 2722 mk 19u CHR 116,8 3474 /dev/snd/controlC0 [root@localhost ~]# ps -fed|grep 2722 mk 2722 1 0 12:51 ? 00:00:00 /usr/libexec/mixer_applet2 --oaf-activate-iid=OAFIID:GNOME_MixerApplet_Factory --oaf-ior-fd=33 [root@localhost ~]# ps -fed|grep 2600 mk 2600 2480 0 12:51 ? 00:00:06 /usr/bin/pulseaudio --log-target=syslog Oh, digging into coreutils sources reveals that + indicates acl permissions. Right, on a working system I get: [root@localhost ~]# getfacl /dev/snd/pcmC0D0p getfacl: Removing leading '/' from absolute path names # file: dev/snd/pcmC0D0p # owner: root # group: root user::rw- user:gdm:rw- user:mk:rw- group::rw- mask::rw- other::--- Next time sound stops working I will run getfacl instead of ll ...
I get the same thing (and others searching my site have noticed the same error). I.E. after resume sometimes the sound is not available. The applet popped up by the laptop volume control keys is grayed out. And starting gnome-volume-control manually reports "No volume control Gstreamer Plugins and/or devices found". Another suspend/resume cycle usually restores working sound. My system is currently in the "no sound" state, so: $ ll /dev/snd/ total 0 crw-rw----+ 1 root root 116, 13 2007-11-28 09:21 controlC0 crw-rw----+ 1 root root 116, 6 2007-11-28 09:21 controlC1 crw-rw----+ 1 root root 116, 12 2007-11-28 09:21 pcmC0D0c crw-rw----+ 1 root root 116, 11 2007-11-28 09:21 pcmC0D0p crw-rw----+ 1 root root 116, 10 2007-11-28 09:21 pcmC0D1c crw-rw----+ 1 root root 116, 9 2007-11-28 09:21 pcmC0D2c crw-rw----+ 1 root root 116, 8 2007-11-28 09:21 pcmC0D3c crw-rw----+ 1 root root 116, 7 2007-11-28 09:21 pcmC0D4p crw-rw----+ 1 root root 116, 5 2007-11-28 09:21 pcmC1D0c crw-rw----+ 1 root root 116, 4 2007-11-28 09:21 pcmC1D0p crw-rw----+ 1 root root 116, 3 2007-11-28 09:21 seq crw-rw----+ 1 root root 116, 2 2007-11-28 09:21 timer $ getfacl /dev/snd/pcmC0D0p getfacl: Removing leading '/' from absolute path names # file: dev/snd/pcmC0D0p # owner: root # group: root user::rw- user:gdm:rw- group::rw- mask::rw- other::---
Pretty sure this is a dup of bug 384271. Until we get this fix pushed out as an update, you might be able to restore the sound permissions by switching VTs after resume, as mentioned in the other bug. *** This bug has been marked as a duplicate of 384271 ***
I just found mixer_applet2 (from gnome-applets-2.20.0-8.fc8) was using 100% - I noticed that some time after a resume. But sound works fine (Rhythmbox and mplayer) Attaching gdb to mixer_applet2: (gdb) thread apply all bt Thread 2 (Thread -1222325360 (LWP 2853)): #0 0x00110402 in __kernel_vsyscall () #1 0x00687ac3 in __poll (fds=0x712ff4, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x00cf1576 in task_monitor_alsa (data=0x85a3400) at gstalsamixer.c:405 #3 0x00174eb6 in gst_task_func (task=0x83f6a90, tclass=0x8642580) at gsttask.c:192 #4 0x0050b2b8 in g_thread_pool_thread_proxy (data=0x8642610) at gthreadpool.c:265 #5 0x0050972f in g_thread_create_proxy (data=0x8642700) at gthread.c:635 #6 0x0075050b in start_thread () from /lib/libpthread.so.0 #7 0x00691b2e in clone () from /lib/libc.so.6 Thread 1 (Thread -1208591776 (LWP 2849)): #0 0x00110402 in __kernel_vsyscall () #1 0x00687ac3 in __poll (fds=0x712ff4, nfds=10, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x004e9583 in g_main_context_iterate (context=0x83eb508, block=1, dispatch=1, self=0x83c4530) at gmain.c:2996 #3 0x004e98f9 in IA__g_main_loop_run (loop=0x83f50f8) at gmain.c:2898 #4 0x002d8813 in bonobo_main () from /usr/lib/libbonobo-2.so.0 #5 0x002d6a79 in bonobo_generic_factory_main_timeout () from /usr/lib/libbonobo-2.so.0 #6 0x002d6b03 in bonobo_generic_factory_main () from /usr/lib/libbonobo-2.so.0 #7 0x001c6101 in panel_applet_factory_main_closure () from /usr/lib/libpanel-applet-2.so.0 #8 0x001c61e5 in panel_applet_factory_main () from /usr/lib/libpanel-applet-2.so.0 #9 0x0804f083 in gtk_vscale_new () #10 0x005d4390 in __libc_start_main (main=0x804ef70 <gtk_vscale_new+13524>, argc=3, ubp_av=0xbfa17bc4, init=0x80504e0 <gtk_vscale_new+19012>, fini=0x80504d0 <gtk_vscale_new+18996>, rtld_fini=0x5ad940 <_dl_fini>, stack_end=0xbfa17bbc) at libc-start.c:220 #11 0x0804bcb1 in gtk_vscale_new () (gdb) c But I noticed: [root@dev-mk ~]# ll /proc/2849/fd total 0 lrwx------ 1 mk mk 64 2007-12-14 10:57 0 -> /dev/null lrwx------ 1 mk mk 64 2007-12-14 10:57 1 -> /dev/null lrwx------ 1 mk mk 64 2007-12-14 10:57 10 -> socket:[18745] lrwx------ 1 mk mk 64 2007-12-14 10:57 11 -> socket:[18747] lrwx------ 1 mk mk 64 2007-12-14 10:57 12 -> socket:[18750] lrwx------ 1 mk mk 64 2007-12-14 10:57 13 -> socket:[18754] lrwx------ 1 mk mk 64 2007-12-14 10:57 14 -> socket:[18751] lrwx------ 1 mk mk 64 2007-12-14 10:57 15 -> socket:[18790] lrwx------ 1 mk mk 64 2007-12-14 10:57 16 -> socket:[18791] lr-x------ 1 mk mk 64 2007-12-14 10:57 17 -> pipe:[18895] l-wx------ 1 mk mk 64 2007-12-14 10:57 18 -> pipe:[18895] lrwx------ 1 mk mk 64 2007-12-14 10:57 19 -> /dev/snd/controlC0 (deleted) lrwx------ 1 mk mk 64 2007-12-14 10:57 2 -> /dev/null lrwx------ 1 mk mk 64 2007-12-14 10:57 3 -> socket:[18740] lr-x------ 1 mk mk 64 2007-12-14 10:57 4 -> pipe:[18742] l-wx------ 1 mk mk 64 2007-12-14 10:57 5 -> pipe:[18742] lr-x------ 1 mk mk 64 2007-12-14 10:57 6 -> pipe:[18743] l-wx------ 1 mk mk 64 2007-12-14 10:57 7 -> pipe:[18743] lr-x------ 1 mk mk 64 2007-12-14 10:57 8 -> pipe:[18744] l-wx------ 1 mk mk 64 2007-12-14 10:57 9 -> pipe:[18744] [root@dev-mk ~]# ll /dev/snd/controlC0 crw-rw----+ 1 root root 116, 6 2007-12-14 10:26 /dev/snd/controlC0 [root@dev-mk ~]# lsof /dev/snd/controlC0 [root@dev-mk ~]# ll /dev/snd/controlC0 crw-rw----+ 1 root root 116, 6 2007-12-14 10:26 /dev/snd/controlC0 [root@dev-mk ~]# top Has /dev/snd/controlC0 been deleted and created again by HAL, and now the mixer is busy talking to a device that doesn't exist? Is this another incarnation of the same problem, or should create another issue?