Comment 28 for bug 486154

Revision history for this message
Robert Schroll (rschroll) wrote :

Since we have some new people following this now, and our history of trying to track this down has been long and convoluted, I though it might help for me to summarize my understanding of the current situation. As you read this, please keep in mind that I have no idea what I'm talking about. The following explanations are likely incomplete or incorrect. Please note any corrections you see.

Goal: We would like to have the motherboard/PC speaker beep when there is a system bell event. (For example, when there is a backspace on an empty like of a terminal.) Prior to Karmic this was the behavior. In Karmic, there are a number of things that get in the way, leading to a variety of different behaviors.

Issue #1 -- The pcspkr kernel module, which allows Linux to make sounds through the PC speaker, is blacklisted by default. This can be changed by commenting out the line 'blacklist pcspkr' in /etc/modprobe.d/blacklist.conf, or by running `sudo modprobe pcspkr`. Everything following will assume that the pcspkr module is loaded.

Issue #2 -- The first time the pcspkr module is loaded, beeps are sent out the sound card's line out, instead of being played by the PC speaker. Removing and reloading the module sends the beeps to the speaker. So far, this has only been observed by Grondr.

Issue #3 -- Somewhere in the initialization of X or Gnome, the PC speaker volume is set to 0. This can be changed with `xset b on`. Note that, because of bug #280767, you cannot use xset -b to set the volume of the bell. (My guess is that this is an issue in Gnome: if I log into an xterm session, the bell volume is set to 50, whereas it is set at 0 after logging into Gnome. So far, though, we haven't found where this is happening.)

Issue #4 -- Metacity is trapping system bell events and using libcanberra to play the sound file /usr/share/sounds/ubuntu/stereo/bell.ogg. This trapping occurs even when the PC speaker has been enabled through solving #1 and #3. (Later, I'll provide what evidence I have that this is indeed Metacity.) So far, the only way to stop this behavior is to remove (or rename) bell.ogg. Unable to play the file, Metacity falls back to ringing the PC speaker.

In my opinion, this is the major problem. If Metacity is going to interfere with the system bell events, it should offer some configuration options! Given that Pulse Audio has module-x11-bell, which could play back an audio file for system bell events, I fail to understand why Metacity needs this feature.

Issue #5 -- If you would like to restore bell.ogg to be played for system bell events after removing it, you must restore the file, delete ~/.cache/event.sound.cache.<long random (?) string>, and restart your session. Why this Pulse Audio cache file is important here has yet to be explained.

Issue #6 -- Metacity limits the playback of sounds for the system bell to 1Hz. See bug #430203.

Issue #7 -- Compiz does not do anything to handle system bells. If issues #1 and #3 have not been addressed, system bell events will not produce any sound. If they have, the PC speaker beeps as desired, without any futzing with bell.ogg. Under Compiz, the "Sound Preferences" "Sound Effects" tab still gives options for the alert sound, even though it (apparently) has no way of playing these sounds at system bell events! (IMHO, this is another good reason to remove bell playback from Metacity -- it gives one less thing to try to match in Compiz.)

So that's my understanding of the problem. If you are experiencing behavior different from what I've described, please let us know. Note that this bug involves the interaction of the kernel, X, and the window manager, and has two states that could be considered "working" (playback of bell.ogg and playback through the PC speaker). So you must be specific as to what exactly is going on!

Appendix: Are you sure it's Metacity and not Pulse Audio?

Mostly. I have three lines of evidence that point to this:

1) Attempts to disable the Pulse Audio's trapping of the system bell haven't accomplished anything. module-x11-bell is not loaded. Moving the .so file associated with this doesn't change anything. Removing the bell.ogg sample (via pacmd) doesn't change anything. Daniel notes that this module is only loaded in Lucid. (So debugging this problem six months from now will be even more fun!)

2) bell.ogg isn't played under Compiz as it is under Metacity. The bell repeat is normal under Compiz, while it is slowed under Metacity.

3) The source of Metacity shows code that seems to catch system bell events, use libcanberra to play back an alert sound, and fall back on the PC speaker in case of errors. (See lines 278-324 of http://git.gnome.org/cgit/metacity/tree/src/core/bell.c This isn't quite what's in Karmic, but it looks pretty close. I think.) Depressingly, the code doesn't reveal any obvious options that are checked before doing all of this, so I don't think this is a case where we've just been missing the relevant configuration file.