[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it

Nic Shakeshaft 486154 at bugs.launchpad.net
Fri Sep 24 03:26:57 BST 2010


Having struggled with this for ages, just thought I'd post the
(extremely hacky!) workaround which finally got the system bell working
normally for me, in case it's of any help to anyone. This is for Lucid.
There were two issues for me: first, the fact that the pcspkr kernel
module (when removed from blacklist) loads too early and hence fails to
do anything, as Grondr points out above.

Second, the window manager's "audible bell" setting (Compiz in my case -
I haven't checked, but it may be the same for metacity) appears to be
overruled by pulseaudio's attempt to capture system bells and replace
them with a sampled sound (using module-x11-bell), such that these
settings in gconf-editor, etc., don't actually do anything. For love nor
money, I can't stop pulseaudio from doing this, but have at least
discovered that the window manager's "audible bell" setting DOES take
effect if it is applied AFTER pulseaudio has finished doing its thing.
With Compiz, for example, this means that toggling 'General Options' ->
'Audible bell' in CCSM (System -> Preferences -> CompizConfig Settings
Manager) off and then back on again restores normal bell behaviour!

Doing this manually after every boot is predictably annoying, but
fortunately it can be scripted. For simplicity, I've put the workarounds
for both bugs into the same executable script, ~/bin/sysbell_hacks, and
added it to "Startup Applications" so that it runs as Gnome loads, after
login. Here's the script:

"""
#!/bin/bash

 # Make sure gnome and pulseaudio have finished loading
sleep 30s

 # pcspkr kernel module insertion bug: remove (if not blacklisted) and reinsert the module
sudo modprobe -r pcspkr
sudo modprobe pcspkr

 # window manager setting override hack: toggle the audible_bell flag
gconftool-2 --set "/apps/compiz/general/allscreens/options/audible_bell" --type bool "false"
sleep 1s
gconftool-2 --set "/apps/compiz/general/allscreens/options/audible_bell" --type bool "true"
"""

As I said... hacky. This works (at least for me...) with compiz, but on
the off-chance that something similar is happening with metacity, its
users might just try replacing the compiz setting in the script above
with "/apps/metacity/general/audible_bell", in both of the gconftool-2
commands. No promises!  :)

-- 
System beep broken in Karmic despite heroic efforts to fix it
https://bugs.launchpad.net/bugs/486154
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is a direct subscriber.

Status in The Metacity Window Manager: New
Status in “libcanberra” package in Ubuntu: New
Status in “metacity” package in Ubuntu: Triaged
Status in “pulseaudio” package in Ubuntu: Invalid

Bug description:
Between Jaunty and Karmic, a number of changes were made to keep the PC speaker from beeping.  As part of this, system bell events are now captured by metacity, which uses libcanberra to play a sound.  For users without speakers, this fails to be useful.  The current setup makes restoring the old behavior extremely difficult.

The absolute show stopper is that metacity traps audible system bell events.  This behavior is, as best we can tell, not configurable.  The attached patch keeps metacity from capturing system bell events.  It also removes the sound playback capability.  As Lucid will be using pulse audio's module-x11-bell to play sounds for system bell events, it is not necessary for this capability to be in metacity.  Additionally, this removes the discrepancy between metacity's and compiz's handling of system bell events.

There are several other difficulties in enabling the system bell:
1) Even if it is taken out of the blacklist, the pcspkr module may not load properly.  Another modprobe may be necessary to get it loaded.  See bug #398161.
2) Something in Gnome's startup does the equivalent of `xset b off`, so `xset b on` must be run on every login.  (Note that bug #280767 keeps you from setting the bell volume with xset.)
3) A number of settings in gnome-terminal and gconf may keep the shell from sounding system bell events.

Comments #28, #34, and #50 give more detailed summaries of the various problems.






More information about the Ubuntu-sponsors mailing list