Description of problem: On a current "rawhide" system, no system sounds are emitted although "Play System Sounds" is checkmarked in "gnome-sound-properties". Version-Release number of selected component (if applicable): control-center-2.21.5-2.fc9 How reproducible: Always. Steps to Reproduce: 1. Log in to "GNOME" session. 2. Clock panel icon to launch some application. Actual results: Application is launched but no sound is played. Expected results: Application is launched and a sound is played. Additional info: Sound in general seems to work though: clicking "Play" buttons in "gnome-sound-properties" associated with particular events triggers the corresponding system sound to be played correctly. This feature used to work until about 1 month ago, and it definitely works in F8. Some relevant components are: - alsa-1.0.15-1.fc9, - gnome-session-2.21.5-1.fc9, - kernel-2.6.24-2.fc9, - pulseaudio-0.9.8-5.fc9.
A downgrade to control-center-2.21.4-3.fc9 solves the issue. In the same time, Xft font preferences are applied again, too, see bug 429442. So, it looks like this also related to (fixed) upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=510925
Font settings have nothing to do with sounds, which is what the upstream bug fixes, but the fact that it works by downgrading the settings-daemon is a hint.
Of course this is only the case through their common handling by the gnome-settings-daemon. Btw, I haven't downgraded gnome-settings-daemon because this was the initial release. I have simply uninstalled it from my system. Anyway, comment #1 was rather meant to inform users about the origin of the problem - there have been many pulseaudio issues lately, and at least here, the culprit was something else. Since bug 429442 has had exactly the same cause, closing this bug as (fixed) UPSTREAM, too.
After upgrading from the last working package versions to current "rawhide" including control-center-2.21.90-5.fc9 , gdm-2.21.6-1.fc9 , gnome-settings-daemon-2.21.90.1-2.fc9 , Xft settings do get applied now as announced upstream but system sounds are gone again. However, they can be played by opening "System > Preferences > Hardware > Sound" and clicking the respective event buttons.
Can I say that I said so? The sounds will only work with: - GNOME applications (applications that link against libgnomeui, and call gnome_program_init()) - login and logout sounds don't work because of what's probably a race in starting up PulseAudio (see bug 428415)
(In reply to comment #5) > Can I say that I said so? Euh? Seriously, NEEDINFO implies that I am expected to report further details, but I do not see what else to report. I do agree that the login/logout sound problem is a different issue, but this issue applied to both old and new setup with/without gnome-daemon-settings. What has changed though is that even for the latest "rawhide" packages, system sounds which are played e.g. when clicking a panel launcher icon are absent. And the panel actually -is- a GNOME application, right?
I managed to reproduce this. Another bug in gnome-settings-daemon. Simply launch "esdctl allinfo" on a working and a non-working system, and see that the sample cache is pretty much empty on the non-working system. (In reply to comment #6) > (In reply to comment #5) > > Can I say that I said so? > > Euh? Seriously, NEEDINFO implies that I am expected to report further > details, but I do not see what else to report. I do agree that the > login/logout sound problem is a different issue, but this issue applied > to both old and new setup with/without gnome-daemon-settings. What has > changed though is that even for the latest "rawhide" packages, system > sounds which are played e.g. when clicking a panel launcher icon are > absent. And the panel actually -is- a GNOME application, right? If the panel was started after the gnome-settings-daemon's sound module was loaded, it wouldn't be able to play sound files. What I was asking was whether you could verify and reproduce the problem with a known-GNOME application that wouldn't race with gnome-settings-daemon on startup.
I can't reproduce the problem with gnome-settings-daemon-2.21.91-3.fc9. Could you please test with that one? If you can reproduce the problem, could you please check that "esdctl allinfo" shows a nearly empty list of samples?
I can reproduce on new logins. I think gnome-settings-daemon isn't caching the samples properly.
$ esdctl allinfo server version = 0 server format = 0x00000021 server rate = 48000 sample 1 name = native.pulse-hotplug sample 1 format = 0x00000010 sample 1 rate = 0 sample 1 left = 256 sample 1 right = 256 sample 1 length = 0
gnome-settings-daemon starts before the login sound in gnome-session, so gnome-session hasn't started PulseAudio yet. gnome-settings-daemon tries to launch PulseAudio using gnome_sound_init() which will only work with esd (with auto_spawn enabled), so never loads the samples in the cache.
The bug is (again) races between gnome-session and gnome-settings-daemon. See: http://bugzilla.gnome.org/show_bug.cgi?id=466458#c15
Issue fixed in gnome-settings-daemon-2.21.92-1.fc9.