System beep broken in Karmic despite heroic efforts to fix it

[Grondr]

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.

[Philip Muškovac (yofel)]

Thank you for taking your time to report this bug and helping to make Ubuntu better. I don't know too much about this issue but this should be a result of bug 77010. Did you try the workaround described in bug 398161?

[Grondr (grondr)]

Yes, I'd seen bug #77010 very early on when trying to debug this, and I also tried the workaround in bug #398161 (which is to rmmod and then modprobe the module again), and the workaround does not work for me. (I can easily
see that rmmod made the module vanish and that modprobe puts it back, but that doesn't restore functionality; I tried it again just now to make sure.)

So thus far, the -only- way I've been able to make the speaker show any signs of life is via "beep -e /dev/input/by-path/platform-pcspkr-event-spkr", and "echo -n '\a'" and all the other
methods I'd expect to cause beeping still don't.

[Grondr (grondr)]

Btw, I just verified that the missing system bell is -not- coming out of either the line-out or the center-out jacks on my motherboard; I hooked up speakers and verified that both jacks give output when I play a random audio file through mplayer, but the missing system bell isn't there.

Oddly enough, just "beep" with no arguments now -does- give a system beep (whether or not I have anything plugged into a jack), as does the prior call with -e dev/input/by-path/platform-pcspkr-event-spkr. I looked in ...by-path and event-spkir is still a symlink to event5, so I'm not sure how beep is currently working with no arg or the original arg. The machine's been up now for 4 days 14 hours, so I'm not even sure it's been rebooted since the last time I checked this.

But yet everything else that should beep---^G in Emacs, echo -a '\a' in bash, rubout at an empty line in gnome-terminal---still fails to give any indication of beepingness.

This regression is currently a blocker for my moving to Karmic; does anyone have any ideas for other things I can check?

Thanks.

[Grondr (grondr)]

Still no joy.

I just tried booting the Karmic LiveCD---hence running in 32-bit mode. I repeated all of the steps listed above, and the behavior is unchanged. The "beep" program continues to work (assuming, of course, that you've modprobed pcspkr, which is the first thing I did while reproducing all the steps above, and then enabled universe and apt-getted it). But nothing else. Though I -did- notice (while shutting down the 64-bit system booted from the normal hard disk) that I got a beep from the internal speaker the instant I typed "sudo reboot"; I don't recall if that was happening at the very beginning of my testing. But I cannot get any of the normal method of beeping to work, whether I'm in X or have booted directly into single-user mode (by editing the startup in grub to be "single" instead of "quiet splash").

Still a blocker for my using Karmic. Those of us with desktops and who don't listen to music all day -need- that system bell to work, since there is no other audio output available. And still a regression---as above, I booted the 6.06 LiveCD and the bell works fine there.

Btw, I figured out (before trying the LiveCD) that just after the machine comes up (with pcspkr -removed- from the blacklist so it's loaded on boot), beep needs the -e arg to beep. After I've done rmmod pcspkr; modprobe pcspkr, that still works, -and- beep with no arg works (even though no additional files have appeared in /dev/input/by-path/, particularly not anything mentioning event0). So this might explain part of the putative workaround mentioned above (but that workaround does not work for me).

[Grondr (grondr)]

Ah, and my comment above about reboot---I just tried "shutdown -r 3" from the LiveCD, and -that- beeped the speaker! "echo foo | wall" also beeps.

I rebooted the normal 64-bit system and noticed that "echo foo | wall" didn't beep the system bell. (Although I was also ssh'ed in from elsewhere and -that- machine's bell beeped when wall emitted the message.) If I did the rmmod/modprobe trick, -then- "echo foo | wall" beeped both bells (the system bell of the machine running Karmic, and the system bell of the other machine that was ssh'ed into it).

So clearly the rmmod/modprobe workaround -is- doing something. But not enough---still no bell in single-user mode, even if X has never run, or in X, from Emacs, or bash, etc. --BUT---:

I've discovered that if I do rmmod/modprobe on a fresh boot (now back to experimenting on my normal 64-bit boot, not the LiveCD), no beep, If I do "echo foo | wall", that beeps, though only -after- the rmmod/modprobe (it won't beep if I do it on a freshly-booted system that has only loaded pcspkr once). And -THEN-, rubout at bash beeps, as does ^g in Emacs, BUT ONLY outside of X. This works whether I've booted single-user or if I've done C-A-F1 to get a non-X shell and logged into that.

I've also tried "service gdm stop; service gdm start" and that hasn't helped. (I figured the wall is obviously initializing -something-, but restarting gdm after that doesn't help.) I made sure to do "xset b 100" before these tests, since every time gdm comes up, it's apparently setting the bell volume to zero ("xset q" reads bell volume 0% unless I reset it)---where is gdm doing this?

So I'm obviously starting to pry this problem open a bit---I can get beeping outside of X (both via rubout at an empty bash command prompt, or in an X-less Emacs) iff and only if I (a) rmmod/modprobe pcspkr, and then -after- that, do something that causes beeping (like "echo foo | wall'; haven't retried doing something like "shutdown -r 3; shutdown -c" but I'm betting that would work too). But inside of X, still no dice, even after I can get beeping reestablished outside of X, so I'm not all the way there yet.

[Grondr (grondr)]

Btw, these tests under X that I'm doing---I'm doing them typing directly on the machine's actual keyboard and using its actual display. Don't get confused by my comments about ssh'ing in from elsewhere---I'm making sure to run the tests directly on the machine's actual I/O hardware so I can't get faked out by some unknown weirdness with X forwarding or something like that; all of the X traffic is on localhost.

[Robert Schroll (rschroll)]

I'm having the same problem on a Presario 2100 running 32-bit Karmic. Running `modprobe pcspkr` enables beeping from the ttys, but Pulse Audio continues to handle the system bell for X. Please let me know if you need more hardware info from me, but this really looks like a software issue to me.

One further solution that doesn't work: Several guides suggest that one can get Pulse Audio to handle the system bell by loading the 'module-x11-bell' module (using `pactl load-module`). However, I don't seem to have this module loaded by default -- it doesn't show up in `pactl list`. FWIW, I can load this module, getting it to show up in `pactl list`, and then unload it, but this doesn't change anything about the system bell.

[Grondr (grondr)]

I now think that Gnome, Metacity, or Pulseaudio are implicated. The hardware and X itself are probably not. Details:

I think I've managed to pry this bug quite a bit farther open, but it's not quite there yet. In particular, I -can- get the system bell to work under bare X as any user. And I can get it to work under the normal window manager, but only as root, and I haven't been able to reproduce the setup, despite installing from the 9.10 image onto a spare disk and starting over. (Note also that for a while I thought this was an X bug and opened bug #489855, which will give you my entire X configuration; I'll go back and amend that shortly.)

Here's what I've done:

First, I realized I could simplify the situation by booting my original installation in recovery mode, logging in as myself, and doing "xinit". Assuming I've done the rmmod/modprobe pcspkr step (since it's already out of my blacklist but that's required to work around some sort of ordering bug), then if I rubout on an empty line in the xterm I get from xinit, I -do- get the system beep! It also works, of course, if I call xkbbeep. So clearly X itself is capable of beeping the system bell in Karmic, if it's not interfered with. (Also, xset does change the bell pitch and duration---but the longstanding bug where the first arg [supposedly volume] is incorrectly -also- interpreted as duration is still with us---looks like "xset b vol pitch dur" is interpreted as "xset b dur pitch dur".)

My next move was to exit out of the xterm and do "startx" instead. In the resulting gnome/metacity/pulseaudio interface (e.g., what I'd get if I'd just done a normal boot), none of the X beeping worked. Note that I -can- still exercise the hardware beeper either by calling "beep" with no args (which produces a different-sounding beep) or by doing "echo foo | wall" (which produces yet a -third- different beep---that one, I think, is the true default hardware beep which matches what the machine's BIOS produces on boot).

So I logged out of the gnome and then did "sudo bash". (Yes, this still left my homedir pointing at my default user directory, which I hadn't been thinking about too carefully. More on that below.) I tried "xinit" as root and that xterm also worked correctly. I exited the xterm and tried "startx", which was the very first time root had run gnome. And -that- UI -does- work---if I start a gnome-terminal, rubout at an empty line beeps, xkbbeep beeps, and ^G in Emacs beeps. Could this be some sort of permissions problem? (It continues to work after rebooting---as long as my window system is running as root, things work. Yuck.)

Note: I'd run both "gconf-editor" -and- "sudo gconf-editor", both while logged in as me, while trying to debug this over the last few days, and I suspect that the latter may therefore have been altering root's settings. (I'd been under the impression that gconf-editor required privileges, but I suspect not.) I have, however, since run gconf-editor as both myself and as root and used the "find" command to find everything that matches the string "bell" in its name or setting, and stepped through them all with lots of downarrows. I believe that...

[Grondr (grondr)]

Robert: It looks like the reason module-x11-bell isn't loaded by default is because it's commented out in /etc/pulse/default.pa (along with the load-sample mentioning it near the top of that file). Presumably, uncommenting and restarting pulse (or just rebooting) would load it. But of course, unless pulse can know to beep the -system- beeper (I don't know if it can), this doesn't necessarily help me (or you). Though if loading that -still- means that xkbbeep (etc) don't produce any output on an audio-out jack (or wherever pulse is trying to route high-quality sound), then it would mean that gnome/metacity/pulse is just throwing away the event entirely, which it could well be doing---at one point in my testing, I tried hooking a speaker up to my line-out, and even though mplayer can certainly play music out that, I never heard the bell come out of that. (And then I unhooked it, so most of my testing hasn't had anything connected there.)

[Grondr (grondr)]

Oh, right, so some quick research indicates the .tdb files in ~/.pulse are Trivial Database Files. Installing the tdbtools package (bug #557819 already complains about their total lack of documentation) lets you run tdbtool on 'em and use commands like "keys" and "dump", although the values of the keys are just strings of binary. I can diff 'em to see if configurations differ, but knowing what the binary means might require a trip to the source code.

pulseaudio --dump-conf and --dump-modules seem promising, although it's annoying that the latter dumps all -available- modules but not (apparently) what it's currently -using- (even with -v). Apparently, though, what you want is "pacmd"; then type list-modules (etc) in its read-eval-print loop; it takes "help" (but not "?"). info & dump may also be useful.

So these might yield some useful debugging info. I note that pacmd's list-modules claims I don't have module-x11-loaded, which makes sense since it's commented-out in default.pa.

Of course, the -real- question is, does PA even matter? Is it what's intercepting the system bell under X, or can something else get in the way?

[Robert Schroll (rschroll)]

We seem to be having slightly different problems - I am getting a sound out of my speakers when I would expect a system beep. What I'm trying to do is go back to the ugly PC speaker beep that I know and love. I was guessing that the sound was being produced by pulse audio, and it seems that module-x11-bell is the one that would do this. But since this module isn't loaded, it must be something else.

Nonetheless, I suspect that we're both looking for the same solution. Something is grabbing events headed for the system beep. We just need to figure out what this something is and how to disable it.

I wonder, in the cases where you can get the beep, is pulse audio running? If so, are the same modules loaded as usual? (You can get a list of the loaded modules with `pactl list`, though that also gives a bunch of other info as well.)

[Robert Schroll (rschroll)]

I've found two work-arounds. Let me know if either works for you.

Workaround #1
Whatever is trapping system bell events tries to play the file /usr/share/sounds/ubuntu/stereo/bell.ogg. If I rename this file, it falls back to the using the system bell. So long as the PC speaker is enabled (`sudo modprobe pcspkr` and `xset b on`), it now beeps when I expect it.

Workaround #2
xkbevd is a daemon that can execute specific commands on given X events. If I create the file ~/.xkb/xkbevd.cf with the contents 'Bell() shell "beep"' and run `xkbevd`, beep will be executed (making a beep) every time there's a system bell event. With this, I get both the PC speaker beep and the bell.ogg sound. But if I didn't have my speakers connected, this wouldn't matter.

[Grondr (grondr)]

Robert: I think actually we had exactly the same problem, and your workaround works for me. I'll explain, 'cause it'll help in debugging this for real.

First off, I've now gotten to a state where my system bell is coming out of line-out. It wasn't before. I'm reasonably sure that this was because of my testing methodology: the first thing I did was to undo the blacklisting of pcspkr in /etc/modprobe.d/blacklist.conf. Then, almost all of the time, my testing after a boot started with rmmod pcspkr; modprobe pcspkr (since apparently it loads at the wrong point during boot when unblacklisted), and doing -that- kills the system bell coming out of line-out! So I thought I never got a bell, when instead I'd killed it. But booting and -not- doing the rmmod/modprobe allowed that to work.

(But it is -completely- unclear to me how the reload of pcspkr tells -PA- to stop emitting its bell!)

While discovering this just now, I also discovered that -something- had recently muted my Main in alsamixer! And -something- had caused the Mute button in System -> Preferences -> Sound -> Output volume to be muted! I -know- for a fact I did not touch either one. I suspect they get reset somewhere else in the window system when I was running as root or a test account and something leaked in some direction. I'm pretty damned tired of the amount of behind-my-back futzing around Ubuntu's currently doing to system sounds. I'm pretty sure this didn't screw up my test results, though, since I've been pretty careful to review my alsamixer settings almost every time, just in case. (I discovered this when, as part of testing line-out, I couldn't even play music through it.)

Other problem people may run into: I tried your first workaround and renamed /usr/share/sounds/ubuntu/stereo/bell.ogg to bell.ogg.KILLED in the same directory. Whereas before then, I was getting that noise out of line-out in a gnome terminal, the noise vanished when I did that. (And I had not yet done the rmmod/modprobe, so it was expected that I heard nothing from line-out and nothing from the motherboard speaker.) I then immediately renamed bell.ogg.KILL to bell.ogg and my sound was STILL GONE! I tried logging in and out; I tried rebooting. Nothing. Uh oh... The non-pc-speaker bell sound had seemed to have gotten itself permanently killed---really annoying, since then I -couldn't- get a bell except through the pc speaker, so if I ever changed my mind about this, I'd have been stuck. (And I might well have to change my mind several months from now when the machine might wind up getting placed too far away to hear its internal bell.)

I figured that the lack of bell.org being around got cached -somewhere- in pulseaudio and I needed to clear that cache. My suspicion was ~/.cache/event-sound-cache.tdb.d19e9db8691a26d6165e5be74ac83637.x86_64-pc-linux-gnu, since that's one of several files that a "find / -mmin -120 -ls" showed had changed recently. I tried renaming it by suffixing .OLD to it. Creating new gnome-terminals didn't bring back my PA bell, but logging out and in again recreated the file. The new and old files are quite different:

Running tdbtool on the old one and sayi...

[Robert Schroll (rschroll)]

Grondr wrote:
> Robert: I think actually we had exactly the same problem, and your
> workaround works for me. I'll explain, 'cause it'll help in debugging
> this for real.

That seems like a reasonable assessment. I'll point out a few places where our systems differ. These should be signs of things that /don't/ matter, since the main problems are the same.
>
> First off, I've now gotten to a state where my system bell is coming out
> of line-out. It wasn't before. I'm reasonably sure that this was
> because of my testing methodology: the first thing I did was to undo
> the blacklisting of pcspkr in /etc/modprobe.d/blacklist.conf. Then,
> almost all of the time, my testing after a boot started with rmmod
> pcspkr; modprobe pcspkr (since apparently it loads at the wrong point
> during boot when unblacklisted), and doing -that- kills the system bell
> coming out of line-out! So I thought I never got a bell, when instead
> I'd killed it. But booting and -not- doing the rmmod/modprobe allowed
> that to work.
>
> (But it is -completely- unclear to me how the reload of pcspkr tells
> -PA- to stop emitting its bell!)

I haven't seen this issue. If I comment out pcscpkr from the blacklist file, it loads just fine. I don't have do to the rmmod/modprobe fandango. But if I do, it doesn't seems to affect what's happening on line out.

> Other problem people may run into: I tried your first workaround and
> renamed /usr/share/sounds/ubuntu/stereo/bell.ogg to bell.ogg.KILLED in
> the same directory. Whereas before then, I was getting that noise out
> of line-out in a gnome terminal, the noise vanished when I did that.
> (And I had not yet done the rmmod/modprobe, so it was expected that I
> heard nothing from line-out and nothing from the motherboard speaker.)
> I then immediately renamed bell.ogg.KILL to bell.ogg and my sound was
> STILL GONE!
[...]
> Running tdbtool on the new file was very different: only 5 keys, all in
> en_US.UTF-8, one of which was bell-window-system, and pointing at
> bell.ogg. So clearly that cache file managed to get itself corrupted
> when I renamed the .ogg. (Did you not run into this problem, or did you
> solve it a different way?)

I thought I had managed to rename bell.ogg back and forth a few times without any problems, but now that I've tested it again, I see that it behaves the same way you describe. To restore the line out bell, I have to make sure bell.ogg exists, delete the cache file, and log out and back in.

Incidentally, this has revealed an oddity in how workaround #1 works after several logins, but I'll save that for another post.

> Interestingly, btw, "xset q" is currently showing my bell percentage as
> 0, but I still get a motherboard beep. Not that "xset b 100" would help
> ---due to another bug (mentioned in the report on X which I opened last
> week, pointed to above, which points out that it's at least 4.5 years
> old!), "xset percentage pitch duration" is being wrongly interpreted as
> "xset duration pitch duration". *sigh*... But at least things are
> somewhat working.

After `xset b on`, I find `xset -q` reports a bell percentage of 50.

> So this shows that there are a whole bun...

[Robert Schroll (rschroll)]

One of the reasons I wanted to disable the PA bell was that it only fires about once a second (as discussed in bug #430203) when, e.g., you hold down the backspace key at a terminal prompt. I prefer the old behavior of the PC speaker of nearly-continuous beeping. When I first implemented workaround #1, I found the old behavior was restored.

However, after logging out and back in and re-enabling the beep, I found that it would only beep about once a second. Re-enabling and then disabling the PA bell again didn't change this - the PC speaker would still beep only once a second. Using xkbevd, I could see that bell events were being fired more rapidly that this; it's just that most of them would be ignored.

So I tried creating another, shorter audio file (0.1s) and placing it as bell.ogg. After deleting the cache file and restarting, this new sound was played for system bell events. But despite the short file length, it would still only be repeated about once a second. Deleting this file, I got the PC speaker repeating as rapidly as possible. But a log-out/log-in cycle changed that back to a PC speaker beep once a second! Note that this behavior is robust against deleting the cache file.

What seems to be happening is that the first time a given file is ripped out from under it, the PA beeper dies and the old beep behavior comes back. But the next time it happens, PA survives and rings the PC speaker itself. I can only assume that pulseaudio is learning, evolving, and slowly gaining sentience, and we must kill it now. With fire.

[Daniel T Chen (crimsun)]

On Tue, Dec 8, 2009 at 1:18 AM, Robert Schroll <email address hidden> wrote:
> back.  But the next time it happens, PA survives and rings the PC
> speaker itself.  I can only assume that pulseaudio is learning,
> evolving, and slowly gaining sentience, and we must kill it now.  With
> fire.

No. Delete it from the cache.

[Daniel T Chen (crimsun)]

On Mon, Dec 7, 2009 at 11:58 PM, Robert Schroll <email address hidden> wrote:
> In fact, it doesn't look to me that module-x11-bell is actually loaded
> by PA.  I can rename /usr/lib/pulse-0.9.19/modules/module-x11-bell.so,
> restart, and still have the system bell intercepted!  This confuses me
> to no end.

We don't actually load module-x11-bell in Karmic at all. In Lucid, we do.

Now, let's consider whether your window manager uses libcanberra
fully. I know metacity does. Compiz doesn't.

[Robert Schroll (rschroll)]

> Now, let's consider whether your window manager uses libcanberra
> fully. I know metacity does. Compiz doesn't.

Everything I've reported has been using metacity. If I turn on desktop effects (which switches to compiz, if I'm not mistaken), I don't get any system bells at first. If I enable the PC speaker (modprobe pcspkr and xset b on), then I get the expected beeps with the expected repeat rate.

So point (d) is not a Pulse Audio issue, as I had claimed. Should it be reported again metacity, libcanberra, or both (or something else)? Separately, there the issue of not having any bell in compiz, but my feeling is that that would be suitably mitigated by addressing (b) [and maybe (a) and (c)].

Thanks for the insight.

[Robert Schroll (rschroll)]

I've marked the Pulse Audio bug as invalid.

The bug I feel is in metacity or libcanberra is that there is no (easy) way to disable the system bell played back through the sound card in favor of the PC speaker. (This is point (d) from above.) I don't know whether the problem is in metacity, libcanberra, or both. As best I can tell from src/core/bell.c. metacity isn't checking any settings before it uses libcanberra to play a bell. And libcanberra didn't seem to install any configuration files for me to tweak.

[Grondr (grondr)]

Daniel: If this bug is truly independent of PulseAudio, then why does renaming /usr/share/sounds/ubuntu/stereo/bell.ogg change the behavior? If your argument is that libcanberra is looking at that file, then why is it necessary to remove a -PA- cache file to fix the bell after renaming the file back? Are you saying that libcanberra is dependent upon and/or writing to files that appear to be owned by PA?

Note that I can repeat all these behaviors from either the 32- or 64-bit LiveCD, using its default settings, which I -assume- means it's using metacity and not compiz. By default, module-x11-bell appears to be commented out, as I said above. So who exactly is stealing X bell events? And how do we -stop- it from doing so?

Robert, in response to various items:
(a) The reason you don't seem to need the rmmod/modprobe fandango is that you've been confining your experiments to gnome (or metacity, or whatever). Try booting in recovery mode and logging into an X-less shell. Assuming you do -not- have pcspkr blacklisted, then lsmod | grep pcs at that point should show it. But if you hit rubout at the start of a line in that shell, you'll hear the bell out your line-out, not from the motherboard speaker. If you rmmod/modprobe, -then- a rubout there will -not- come out of line-out and -will- come out of the motherboard. Furthermore, if you type xinit (hence getting into X but not gnome/metacity), you get the same behavior (you can also try rebooting and waiting to do the rmmod/modprobe until you xinit if you'd like to reproduce it the same way). Note that the X bell will have a different pitch than the non-X bell, which has a different pitch than the motherboard bell---three pitches in all. But if you do the fandango, you'll get the motherboard bell, whether you're in X or not. [And note -weird- thing below!]
(b) I think you're right that bug #430203, which I cited as the "slow bell", did make it into Karmic---I looked at bell.ogg in Audacity and the entire sample is only 200ms long, and it's got audio for all of it. But the gnome/metacity bell is still not firing above 1 Hz, so there's a bug/rate-limiter in there -somewhere-.

WEIRD THING #1: I noticed that, if you're -not- in gnome/metacity (e.g., either directly in an X-less shell, or in the shell that xinit gives you), -and- if you've booted with pcspkr -not- blacklisted (so it's loaded) but have -not- done the rmmod/modprobe fandango (so your bell is still being intercepted and is coming out of line-out instead of the motherboard), THE FIRST BELL AFTER AN INACTIVE PERIOD VANISHES. In other words, you're sitting at en empty line in the shell. You hit rubout. You hear NOTHING. You wait a couple seconds. You continue to hear nothing. You hit rubout again. NOW you hear a bell! In fact, I can repeatably cause non-motherboard bell events to VANISH as long as I hit rubout no more frequently than about once every six seconds. If I hit it more frequently than that, the first one after a long gap vanishes, and the rest of them come through. [Note that this might be slightly racy---while I was testing, I managed to hear a bell and then -not- hear one from a rubout less than half a...

[Il_Gattusso (giuseppe-mini)]

Same problem in my system. See bug 493127

GM

[Grondr (grondr)]

Thanks! I just put a pointer in your bug back to here, so hopefully people will see both and figure out if we're talking about the same thing.

[Il_Gattusso (giuseppe-mini)]

New information: Using metacity instead of compiz the system beep works!! any suggestions??

[WeatherGod (ben-v-root)]

Therefore, if indeed the differential is metacity versus compiz, then the problem might be with libcanberra?

[Il_Gattusso (giuseppe-mini)]

uhm.. I don't know. I can't understand why a video manager interacts with sounds... some strange dependency?

[Grondr (grondr)]

[IG: I don't understand your comments re the bell working in metacity -instead of- compiz. If that's true, you're talking about something different than we are. You should also strive to be more precise in your description. For example, when you say "system bell", I'm not sure if you're talking about something coming out of line-out, or out of the motherboard beeper.]

So there are actually a number of bugs here (e.g., the rmmod/modprobe fandango etc), but it's looking like the most-annoying one to work around is the stealing of the X bell events. -Assuming- for the moment that it's metacity or libcanberra (because my tests in X but outside of them "worked", for some value of "worked" modulo repetition rates, and because Robert reports that compiz also doesn't appear to be stealing events), then how do we establish this?

Does anyone have an easy way of running gnome et al without metacity as a test? How about a potential patch one might make to libcanberra to see if the behavior improves?

[Robert Schroll (rschroll)]

In reply to Grondr's post from yesterday:
> But if you hit rubout at the start of a line in that shell, you'll
> hear the bell out your line-out, not from the motherboard speaker. If
> you rmmod/modprobe, -then- a rubout there will -not- come out of
> line-out and -will- come out of the motherboard.

I did not read your previous posts carefully enough. I assumed that when you said a bell coming out of line-out, you meant that bell.ogg was being played. But if I'm reading this correctly, what you actually mean is that you're getting a square-wave sound out of the sound card at first, and then out of the motherboard speaker after the rmmod/modprobe. Is that correct?

Unfortunately, I can't test this with my Karmic machine. It's a laptop without a motherboard speaker, so everything comes out of the built-in speakers. If I get a chance, I'll try a Live CD with my desktop to see if I can replicate this behavior. (I've been putting of upgrading it because of bugs like this one.) I still feel that this problem is unconnected with the other issues we're having (but I've been wrong before!).

> (b) I think you're right that bug #430203, which I cited as the "slow
> bell", did make it into Karmic---I looked at bell.ogg in Audacity and
> the entire sample is only 200ms long, and it's got audio for all of
> it. But the gnome/metacity bell is still not firing above 1 Hz, so
> there's a bug/rate-limiter in there -somewhere-.

I've linked #430203 to an upstream bug, where they seem to have solved this. But I so far there's been no action.

> WEIRD THING #1: I noticed that, if you're -not- in gnome/metacity
> (e.g., either directly in an X-less shell, or in the shell that xinit
> gives you), -and- if you've booted with pcspkr -not- blacklisted (so
> it's loaded) but have -not- done the rmmod/modprobe fandango (so your
> bell is still being intercepted and is coming out of line-out instead
> of the motherboard), THE FIRST BELL AFTER AN INACTIVE PERIOD
> VANISHES.

I cannot reproduce this behavior.

> WEIRD THING #2: If you -are- getting the motherboard bell (meaning
> you've done the fandango), holding down rubout in an X-less shell
> gives you the bell at what seems to be the key-repeat rate, maybe
> 10-20Hz. But if you're in X (e.g., via xinit, not gnome/metacity),
> holding down rubout gives you a bell that's only running at about
> 2Hz. The duty cycle of the X-less bell is close to 100%, but the duty
> cycle of the X bell is closer to 30-50%.

I do, however, see this. (Okay, it's more like 4Hz for me.) Checking with xkbevd, it seems that the rate of bell events has actually slowed down. I thought this might be an issue of keyboard repeat rate, but xset q shows that to be 25 Hz, which seems about right when deleting characters, for example. I have no idea if this is at all relevant to the other problems.

> Obtw, one problem with your workaround #2 is that apparently the X
> bells it plays take a while (maybe I can tighten up their duration,
> but then an isolated bell is harder to hear). This means that, unlike
> the "working" case in older releases, holding down rubout makes it
> -really easy- to get -way- ahead of the beeper

Yep. Things l...

[Robert Schroll (rschroll)]

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 Effect...

[Grondr (grondr)]

Robert: Thanks for the summary. I'm going to prepare a little table for the studio audience to try to make things clearer, especially since you correctly pointed out in comment #27 that there's ambiguity over whether I'm talking about bell.ogg or the squarewave beep coming out of line-out (whoops). I can probably get to that within the next 24 hours; if not, it'll happen maybe Sunday sometime. The idea is to summarize the motherboard & line-out behavior with and without the rmmod/modprobe fandango in an X-less console, in bare X (xinit), and in gnome/metacity. (I'm not going to try compiz unless someone thinks it's necessary; if I did that, I'd do it from a LiveCD to avoid potentially side-effecting my current Karmic install.)

Re the rmmod/modprobe fandango: I'm not the only person who needs to do this. In fact, it would never have occurred to me that it would even change the behavior if I hadn't seen it mentioned in bug #398161 (see comments #1 and #2 in this thread, where Philip asked if I'd tried that workaround). So it's clearly not just me. However, I hadn't realized you were testing on a laptop. I think that to really disentangle things, testers need to try this on a desktop, where you can tell absolutely where the sound is coming from, given that laptops seem to route what I'd call line-out directly to their onboard speaker unless you've got something plugged into the line-out connector---that muddies the water. On a desktop, my motherboard speaker is independent of whether I've got anything cabled into line-out, so I can differentiate conditions that I think you can't.

On a larger note, this might be a problem with Ubuntu in general on this issue---if most of the developers working on these subsystems do their work on laptops, they may not see the issue! Or at least, not all of it.

More tomorrow.

[Il_Gattusso (giuseppe-mini)]

Some more clarification:

1. Starting from ubuntu version 9.10 the system beep has been replaced
from a sound coming from the sound card.
2. If you load the module pcspkr you can ear a sound coming from the pc
speaker but the system don't use it (only at the shut down or with the
beep command)
3. If you load the module snd_pcsp you can ear a beep coming from the
suond card but the system don't use it (only at the shut down or with
the beep command)
4. In my case the sound coming from the sound card was missing (point 1)
and it works only if you disable compiz so I have to understand why
compiz stops that sound.

Any suggestion?

Grondr ha scritto:
> Robert: Thanks for the summary. I'm going to prepare a little table
> for the studio audience to try to make things clearer, especially since
> you correctly pointed out in comment #27 that there's ambiguity over
> whether I'm talking about bell.ogg or the squarewave beep coming out of
> line-out (whoops). I can probably get to that within the next 24 hours;
> if not, it'll happen maybe Sunday sometime. The idea is to summarize
> the motherboard & line-out behavior with and without the rmmod/modprobe
> fandango in an X-less console, in bare X (xinit), and in gnome/metacity.
> (I'm not going to try compiz unless someone thinks it's necessary; if I
> did that, I'd do it from a LiveCD to avoid potentially side-effecting my
> current Karmic install.)
>
> Re the rmmod/modprobe fandango: I'm not the only person who needs to do
> this. In fact, it would never have occurred to me that it would even
> change the behavior if I hadn't seen it mentioned in bug #398161 (see
> comments #1 and #2 in this thread, where Philip asked if I'd tried that
> workaround). So it's clearly not just me. However, I hadn't realized
> you were testing on a laptop. I think that to really disentangle
> things, testers need to try this on a desktop, where you can tell
> absolutely where the sound is coming from, given that laptops seem to
> route what I'd call line-out directly to their onboard speaker unless
> you've got something plugged into the line-out connector---that muddies
> the water. On a desktop, my motherboard speaker is independent of
> whether I've got anything cabled into line-out, so I can differentiate
> conditions that I think you can't.
>
> On a larger note, this might be a problem with Ubuntu in general on this
> issue---if most of the developers working on these subsystems do their
> work on laptops, they may not see the issue! Or at least, not all of
> it.
>
> More tomorrow.
>
>

[Robert Schroll (rschroll)]

Quoth Grondr:
> Re the rmmod/modprobe fandango: I'm not the only person who needs to
> do this. In fact, it would never have occurred to me that it would
> even change the behavior if I hadn't seen it mentioned in bug #398161
> (see comments #1 and #2 in this thread, where Philip asked if I'd
> tried that workaround). So it's clearly not just me.

I've tried a Karmic Live CD on my desktop machine. I get the system beep coming out of the motherboard speaker after a single modprobe pcspkr, whether in X or at a virtual terminal. For obvious reasons, I can't un-blacklist the module, so I can't say whether the behavior would be different if the module was loaded during boot. Did you notice any difference between those two cases, or did you always have the beep come out of your soundcard after the first (and only the first) time pcspkr was loaded?

I also haven't noticed any delay or dropping of system bell events (weird thing #1 from post #20) after the first time pcspkr is loaded. My strong suspicion that your problems with pcspkr behaving oddly on the first load is a hardware-related bug. As you point out, it's certainly widespread. But this is the one problem that is not behaving the same for everyone, at least as far as I can tell.

[Robert Schroll (rschroll)]

> 4. In my case the sound coming from the sound card was missing (point 1)
> and it works only if you disable compiz so I have to understand why
> compiz stops that sound.

If I understand correctly, this has nothing to do with the motherboard speaker. In Metacity, you're getting a sound file (bell.ogg) being played back at system bell events, but you're getting nothing at all in Compiz. Is this correct?

If so, then the issue (#7 in my numbering above) is that Compiz does not play a sound at system bell events, while Metacity does. Compiz isn't stopping the sound; rather, no sound is being made when you're running Compiz. Issues #1-3 have blocked the motherboard speaker. To reenable it, try running `sudo modprobe pcspkr` and `xset b on`. This should allow beeps under Compiz, though you won't get the bell.ogg sound.

IMHO, this illustrates why it's silly for the window manager to be intercepting system bell events. If something must intercept them, let it be Pulse Audio or some other WM-agnostic system.

[Grondr (grondr)]

Robert: Re the rmmod/modprobe fandango I'm doing: I've done a bunch of testing (my next post will detail it), but I'm pretty sure what's going on with rmmod/modprobe is simply a kernel regression---if pcspkr is loaded too early, it doesn't work correctly. So if it's blacklisted, and then loaded by hand by the user once everything is up, that's equivalent to un-blacklisting it, waiting until the system is up, and then doing rmmod/modprobe on it. You didn't see that with the LiveCD because you couldn't un-blacklist it since you're booting off read-only media that specifies the blacklisting. (I don't know how early it can be safely enabled; that'll be some other testing, but that's pretty clearly a kernel regression in my eyes and otherwise unrelated to the rest of the bugs we're tracking down.) This also means that, until the kernel bug is fixed, the easiest thing for people to do is just leave it blacklisted and then put something in rc.local (or equivalent) that modprobes it; that's probably late enough, but I'll find out for sure at some point.

Lots of detailed testing on all the other bugs & aspects of this report in my next post, once I finish editing it.

[Grondr (grondr)]

I've rerun all my tests. I've attached a table and legends for it, since no doubt it would
otherwise be smashed by the automatic reformatting done by launchpad (is there any way to
turn that off?).

Note that EVERYTHING works fine in Hoary, Dapper, and Breezy. I did not test 9.04.
But 9.10 has multiple regressions from the behavior in much older releases.

Things that testers/fixers need to keep in mind:
(a) Logging in from usplash/xsplash is DIFFERENT than booting in recovery mode and doing startx!
    I get various diagnostics in my X log and elsewhere doing startx, -and- the behavior is not
    the same---note the recovery-mode section of the attached table and the presence of --/--
    entries there where there are different results via normal boot into GDM. [Also, I can't
    run alsamixer via startx (it says "alsamixer: function snd_ctl_open failed for default: No
    such file or directory" whereas it works fine in a normal boot -or if I run it in an X-less
    shell in recovery mode. So clearly doing startx from recovery-mode is different than the
    normal xsplash->gdm boot. (Also, startx bitches that I've changed my language and prompts
    to rename my homedir the name of one of the directories -inside- it, which I ignore.)
    [And I can't boot in recovery and do "service start gdm" 'cause that requires a sudo, but
    doing it as sudo presumably then runs gdm as root, not me, muddying the water...]
    NOTE ALSO that the VA state ("vanished first bell") is MUCH more common in all the states
    you can get into from startx, as opposed to a normal boot->gdm, where you're only in that
    state before screwing with xkbbell.
(b) You (probably) need to reproduce at least some of this testing on a desktop, where you can
    tell the difference between line-out and the built-in speaker.
(c) See the very first post in this bug for all the other things I had to enable to get bells in
    gnome-terminal to work so this is even possible, e.g., modprobe pcspkr, alsamixer settings,
    maybe xset b, gconf-editor changes, gnome-terminal checkboxes.
(d) Running xkbevd (w/conf file---see "workaround #2" in comment #12) and killing it again is
    NOT THE SAME as never having run it at all during that boot. Note, for example, the line
    in the direct-boot section, test BL, state 3 (gnome/metacity) vs state 5 (g/m w/xkbevd killed)
    ---{S2/LO,VA} vs {S2/LO} (no VA). Obviously, some state is being kept around. I tried this
    -3 times- to make sure I wasn't hallucinating. Logging out does NOT reset this state.
(e) Each of BL MO NB RM etc tested starting from REBOOT (but not poweroff). Don't just log out!
    (See point (d) above for why not.)
(f) "beep" (from the "beep" package; not installed by default) and xkbbell are not interchangeable!
    Obvious, but let's be clear here about which is getting called when.
(g) Don't pay all that much attention to my bell-frequency notes; those were guesses and may be
    wrong. I'll redo them if tracking down who is generating a bell is required and the frequency
    can tell us; if it's not important for fixing these bugs, though, there's no point.

Results, and where I think the blame lies...

[WeatherGod (ben-v-root)]

Grondr, thank you for your in-depth and exhaustive analysis. It will prove to be very valuable. I have marked this report as "Confirmed" for metacity, and I hope that will help capture the attention of the metacity maintainers.

I think you have a much better handle on what is going on than I do, and doubt I would be able to do a proper summary of the issue. If you are willing, could you please update the description above with a summary of: symptoms, diagnosis/causes, and possible work-arounds. Usually, when I revise a description, I set those things as subsections with headers like so:

=== Symptoms ===
   .......

=== Diagnosis ===
   ....

=== Work-arounds ===
   ....

Bug reports that are nicely formatted like this are more likely to be dealt with by maintainers. I hope this helps get their attention and that they then can resolve this issue for you.

[Tricia (whtiger)]

I also am affected by this. After lots of playing around I got it to do the horrible system bell, which in my case is better than a nice sounding one, but still.

Here's the steps I took to get the workaround:
1) Unblacklist pcspkr in /etc/modprobe.d/blacklist.conf
2) Reboot (or modprobe, whatever)
3) alsamixer, make sure PC Beep isn't muted
4) xset b on
5) xset b 8 (nice and low so it doesn't make my ears bleed)
6) echo -e '\a' (should work)

[Grondr (grondr)]

Oy.

I know this is probably going to be an unpopular discovery, but I am no longer sure this is necessarily a metacity bug. The problem is, then, whose bug -is- it?

I just spent a couple hours hacking around in the metacity source code doing things like commenting out XkbSelectEvents and XkbChangeEnabledControls calls in core/bell.c's meta_bell_init, and finally going so far as to #undef HAVE_XKB in that file and display.c. I could pretty easily cause backspace on an empty line to emit -nothing- (on either the motherboard speaker or line-out), but I couldn't get the functionality I wanted (namely, the old functionality of X bell on motherboard speaker). [Obviously you have to killall metacity & restart it and/or log out & in to see changes, etc.]

Finally it occurred to me to just rename /usr/bin/metacity to a random name, log out, and then log in again. I got an endless spinny cursor because something was trying but failing to start the metacity process, but could still start a terminal window and still got silence on empty-line backspace. [The "beep" command works as always, but that's a completely different mechanism, etc.] I also tried this from a cold-boot, just in case; same behavior.

So while it looks like metacity can correctly snarf up X events so you can get -some- sort of bell, something other than metacity is grabbing and/or killing them, since even if metacity isn't running, there's no bell of any sort on an empty line (and presumably xkbbell would also be silent; i didn't test it). Yet this works without X and in an xterm started via xinit (see my giant table), so what's stealing these events? Some other part of gnome?

Aargh. But at this point, I don't think I can file a bug against metacity for this, except to cause the metacity developers to maybe point their fingers at the real culprit...

P.S. It -is- disturbing that meta_bell_set_audible is a complete no-op (no lines of code), and the comment in bell.h that meta_bell_shutdown is never called also gives me pause---I wonder if -that- is why I was getting different results based on whether xkbbell had -ever- run, since boot (see my giant table again), which smelled of something failing to clean up its state. But the fact that this seems broken even if metacity had never run makes me think it's not metacity's fault (and I suspect the xkbbell stuff is its own state-restoration issue.)

[Donald Allwright (donald-allwright)]

I am interested in getting the sound from a proprietary video conferencing tool to come out of the PC speakers (it uses pulse audio). Having tried manually modprobing pcspkr to no avail I have noticed that when logged into KDE it works fine, but when in Gnome it doesn't work. This suggests the problem is nothing to do with the system bell at all, which in fact does work fine in Gnome.

[Grondr (grondr)]

I'm beginning to wonder if this might be a gtk issue. Or gdm. Or gdk.

Does anyone know how to tell which application might have called XkbSelectEvents or XkbChangeEnabledControls? Can I ask X somehow?

For the moment, I'm reduced to, e.g., doing "apt-get --dry-run build-dep gdm", noting which packages it wants as dependencies, then doing "apt-get source the-giant-list" and then using "rgrep -i bell-or-beep-or-whatever ." to find likely suspects. Unfortunately, there are quite a lot of references to beeps and bells (gads, I wish people would have decided one way or the other what this is called), and a reference in gtk+2.0-2.18.3/gdk/x11/gdkdisplay-x11.c to XkbSelectEvents with some masks, but all in all, this is a terribly time-consuming way to do a whole bunch of trial and error in an enormous hairball of hacks, kluges, and a decade or more of accreated code. How do we find an expert?

[Robert Schroll (rschroll)]

Donald, I fear you've mis-understood what this bug is about. We are trying to get the system beep to come out of the PC speaker, which is that speaker on your motherboard that can only play square waves. You probably don't want to use this for your video conferencing, unless you'll be talking to R2D2 :). I'm guessing that you're going to have to figure out how to get your tool to work with Pulse Audio (or figure out how to kill Pulse Audio before launching your application). If you think you've found a problem with Ubuntu, I think you should open a new bug; your problem seems unrelated to this one.

[Robert Schroll (rschroll)]

Grondr, thanks for your exhaustive efforts to describe the many permutations of this bug. I have only one thing to add: On my 9.04 system, the system bell seems to work exactly as it did in previous versions. So I think what changed, changed between 9.04 and 9.10. Perhaps we need to start diff-ing the sources of potential suspects.

I still remain fairly convinced that this is a metacity problem. (Of course, I used to be fairly convinced that it was a pulse audio problem, so I won't feel slighted if you don't believe me. :) My reasoning is this: Once I've enabled the PC speaker, I can get the old behavior back by switching to compiz, and then go to bell.ogg by switching back to metacity. As I'm switching via the System | Preferences | Appearance | Visual Effects dialog, I'm not being logged in again and I'm not restarting Gnome. All that's happening (I think) is that metacity is being stopped and compiz is started in its place (and vice versa). So whatever is catching system bell events is being started and stopped with metacity. Maybe it's not within the metacity binary itself, but it seems to be tied tightly with the metacity window manager as a whole. That said, I have no explanation of the behavior you describe.

> How do we find an expert?

I'll try annoying the people over in #77010. But I'm not holding out much hope that that will help.

[Grondr (grondr)]

Aha! You've done -exactly- the debugging I was thinking of asking you to do... :) [More, even, since I didn't realize you could easily try out 9.04; I don't have any 9.04 systems and didn't really want to install one just for testing, though i guess I could. I'd assumed this was broken before then.]

The fact that you can make it change by just enabling compiz vs metacity without even logging in or out is actually great news; if it really -is- metacity, that's not a large codebase. Can you be precise about what you're doing to enable/disable compiz so I can try the same tests? Is it just the Visual Effects thing, going from the lowest to the highest "effects" mode? Can you also do something like "ps -elf" or "ps -elf --forest" and diff them to see which processes are running in each case? That's pretty crude, but might give us an idea of where to look.

Thanks!

[Robert Schroll (rschroll)]

> Can you be precise about what you're doing to enable/disable compiz so I can try the same tests?

I had been switching between "None" (metacity) and "Normal" (compiz) in the Visual Effects panel of Appearance Preferences. I just figured out that I can also switch by running "compiz --replace" and "metacity --replace". As far as I can tell, these two methods are the same. But to be sure what's going on, perhaps we should use the command line method from here on out.

As best I can tell, the difference in running processes is:
1) When I first log in, "metacity" is running as a child of "gnome-session".
2) After I switch to compiz (using the Appearance Preferences), metacity is no longer running. Instead, "/bin/sh /usr/bin/compiz --replace" is running at the top level, with child process "/usr/bin/compiz.real --ignore-desktop-hints --replace --indirect-rendering --replace move resize place decoration animation ccp", which has child "/bin/sh -c /usr/bin/compiz-decorator", which has child "/usr/bin/gtk-window-decorator". (Additionally /usr/share/jockey/jockey-backend was started as a separate process. I don't know if this was related or not.)
3) Switching back to metacity, "metacity --replace" is now running at the top level. "compiz" and "compiz.real" have been killed, though "compiz-decorator" and "gtk-window-decorator" (and "jockey-backend") are still running. Switching to compiz again will apparently use the existing decorator processes rather than starting new ones.

So, while compiz seems to have several processes running, the only process unique to metacity is in fact "metacity"

I just tried running "killall metacity" (while using metacity, of course). Sure enought, the window title bars disappeared. So did the bell.ogg sound. However, it was NOT replaced by the PC speaker beep! (Instead I got silence.) System bell events were still being generated (as per xkbevd) and the speaker still worked (as per beep). Starting compiz from this state was enough to restore the beep on system bell events. Perhaps there is some sort of negotiation between X and the window managers about what to do with these events? Maybe I should look in compiz's code to see if there's a section where it tells X not to sent system bell events its way.

[Grondr (grondr)]

Yes, I had the same behavior with "killall metacity" (which I was using because I was recompiling it with various things commented out). I'll run some compiz tests and make sure I can reproduce your results. I think there -is- some negotiation going on, and I'm not sure what happens if a process asks X to hand it events and then dies or is killed; do the events get black-holed? I'll pull down the sources to those compiz processes if I can find it and take a look as well, though it'll be a superficial look. More in a bit.
(Might also be interesting, after switching to compiz and back, to kill the left-behind compiz processes and see if that changes anything.)

Together we'll kill this thing.

[Possibly even with fire. That comment of yours early on had me in stitches.]

[Grondr (grondr)]

I can't quite reproduce your it-must-be-metacity results, because when -I- try compiz, I just lose X bells completely. BUT---metacity is -definitely- doing something wacky. Read on.

Starting from metacity, xkbbell (and rubout at an empty shell prompt) "work" in the same not-really-working manner as always. (And beep also "works", e.g., I hear it on the MB speaker if pcspkr is loaded and line-out otherwise.)

Doing compiz --replace turns out to be a bad idea on my setup---almost all the time, I lose the ability to click on -anything- (including panel objects), I seem to have focus in no window at all (so typein is completely broken), and X logs errors about glibc corruption (double-frees & so forth). I have the logfiles, but that's some different bug I don't want to get distracted by now. (It also doesn't start jockey 'cause it's not automatically looking for drivers, etc.) I have to kill all compiz-related processes (some with -9) to get a window system back, whereupon doing metacity --replace works. (ssh is unaffected; this seems purely some X death, so I can fix things up via ssh from another machine).

Going to Preferences -> Appearance -> Extra, on the other hand, does start up compiz without dumping backtraces into my .xsession-errors file.

However, having done so, xkbbell (and rubout etc) are silent. beep still works.

metacity --replace puts metacity back and gives me the same we-snarfed-your-X-bells behavior as always.

Rebooting didn't change this. (I wondered if I'd screwed up some state trying compiz --replace a couple times and getting those assertion failures, etc, so I tried going back to metacity, then rebooting, then enabling compiz via the Prefs panel.)

Since I'd been poking around in the metacity source, commenting out a thing or two, I figured that maybe my changes caused it to grab something in X and not let go, hence screwing up compiz. So I reinstalled the virgin package (essentially) via "apt-get source metacity; cd metacity-2.28.0; debuild -rfakeroot binary; cd ..; dpkg -i *.deb; killall metacity" and tried again. No change. I also tried rebooting at that point, just in case. Also no change. As long as I'm in compiz, no X bell. Once in metacity, X bell (as in, it's grabbing X bell events and playing bell.ogg at me).

HOWEVER---I have inadvertently found another issue! I was doing most of my development on this in a root shell in Emacs, ssh'ed in from my stable Hoary (!) system (due to be replaced by Karmic as soon as this bug is squashed). In that shell, I typed "metacity" at the prompt.

Whoops.

It spit out "Window manager warning: Screen 0 on display "localhost:10.0" already has a window manager; try using the --replace option to replace the current window manager." AND KILLED THE X BELL ON THE HOARY MACHINE.

I can't get it back. I'll have to boot, or at least restart X, which means the same thing in terms of losing all my state. I'm pissed off.

I also tried this on a laptop running Dapper. ssh'ing into the test Karmic system and, as my normal, unprivileged user, trying to run metacity gave me errors, at about 1 Hz until I killed it, saying "Failed to contact configuration server: ..." etc. ...

[Robert Schroll (rschroll)]

I think I've solved the issue of metacity grabbing audible system bell events. The attached patch contains my changes to metacity (specifically src/core/bell.c). Please give it a try and let me know if it works for you. If not, please let me know. I am a complete novice at dealing with .deb files, so it's very likely that I messed something up and produced an invalid patch.

This patch keeps metacity from grabbing system bell events. As a side effect it also solves the issue of metacity rate limiting the system bell events. It does not completely solve this bug. You still need to load (and possibly reload) the pcspkr module and turn the PC speaker on.

I developed this patch by reverting bits of bell.c back to the version from jaunty. Here's the reasons for the changes, identified by the old line number referenced in the diff:

1) Near line 52, I removed the #include of canberra-gtk.h, since we will no longer be using libcanberra to make bell noises.

2) Near line 281, a large chunk of code is excised. I believe all of this was for playing the bell.ogg sound through libcanberra, but I'm not entirely sure.

3) Also in that area, code was restored to keep meta_bell_set_audible() from being a no-op. The restores the ability of the gconf key /apps/metacity/general/audible_bell to turn the audible bell on and off.

4) Near line 355, the final argument of a call of XkbChangeEnabledControls() is changed. This is necessary to keep metacity from trapping the audible bell events!

As an aside, note that pulse audio's module-x11-bell *can* be used to play the bell.ogg sound in place of the PC speaker beep for system bell events. Since this is much easier to change and configure, I see no reason not to use this in place of the metacity/libcanberra solution for system bell events in future versions.

[WeatherGod (ben-v-root)]

Wow, that's... exhaustive. I'll see if I can flag someone down for you guys and see if they can help you any further.

[Grondr (grondr)]

Confirmed---your patch fixes the issue. Now I can migrate to Karmic without going mad. (I'll make a post showing all the extant bugs & what fixes them, since this is but one part of all the bell lossage we've discovered, but this is certainly the most-annoying one and the one that got us started... :)

And I -absolutely- agree that it's PulseAudio's job to be screwing around with the bell! It's documented, it's configurable, and it'll work with -all- PA-capable window managers, rather than metacity being a weird special case. Pity that this bug started out (see title bar, etc) with my guess that it was PA and not metacity; oh well.

Strictly speaking, I don't think you need part 3 of your patch---I tried tests using the various pieces of it in isolation, and it looks like the bell will be audible even if the #ifdef is replaced by HAVE_XKB_NOPE or some other thing that keeps it commented-out. However, it can't hurt, and it may allow metacity to counteract similar lossage by some other window manager leaving us in a bad state. (Btw, I also made sure that sudo metacity while ssh'ed in from another host no longer stole -its- bell, either.)

I'm pretty sure my testing commented out the line in #4, but I can't remember if I also tried diddling the mask correctly instead. Given that every time gdm gets restarted, the X bell volume is set to zero, it's also possible I had it right at some point but never knew it---if I'd forgotten to do xset b.

And yes, your #2 is necessary---otherwise, you get the motherboard beep -and- bell.ogg played simultaneously (but the beep is not rate-limited, whereas bell.ogg is). [Or, if you haven't loaded pcspkr yet, you get a squarewave beep out the line-out port, along with bell.ogg). I note also that bell.ogg is still delayed, especially the first one after a long silence.

I haven't tried out all the various weirdo permutations I did in my comment #34 (bug-characterization), but since the normal-boot-into-gdm-and-metacity case now works, I'd be very surprised if anything else was broken---things are now working like my pre-9.XX control case.

Also, it looks like the "vanishing bell" problem has itself vanished; this was result (d) in my characterization (e.g., "beep" with 10-second delays would tend to emit a beep every -20- seconds). Looks like metacity was responsible for -that- bit of lossage, too.

Yay!

I suspect somebody should open a bug upstream, directly at metacity's bugtracker, and point them at your patch (and at this entire thread, as motivation for just what a PITA this bit of metacity behavior has been). I'm going to post a step-by-step about how to configure all the moving parts to get bells back as my next post, so somebody searching for it might win (since even with the patch, there's a lot of other stuff that has to get set correctly).

[Grondr (grondr)]

Oh btw, someone else will to have to verify if the patch is well-formed; I applied it by hand, since I was poking around to verify each piece.

[Grondr (grondr)]

Okay, for anyone who's trying to restore the pre-Karmic behavior of beeping, here's what to do. It will give you old-style motherboard beeps when you hit rubout at an empty shell prompt in gnome-terminal or at an empty password prompt during gdm login; it will make xkbbell work; all rate-limiting of bells will be disabled; and bells will be emitted instantly, and not after a sluggish wait of up to a second.

INSTALL PATCH:
(a) [sudo] apt-get build-dep metacity
(b) apt-get source metacity; cd metacity-2.28.0
(c) Apply the patch or hand-edit src/core/bell.c
(d) [sudo] debchange -v 1:2.28.0-0ubuntu1+dontstealbell "Don't steal X bell events." [Note 0]
(e) [sudo] debuild -rfakeroot binary; dpkg -i ../*.deb; killall metacity
(f) metacity & in any shell on your X server screen [-not- via ssh from somewhere else!] metacity runs as you, not root.

FIX DEFAULTS:
(a) alsamixer; raise Beep to 100%; unmute. [Apparently unnecessary for motherboard beeping, but if you want anything -else- to beep later using PulseAudio or by playing bell.ogg or whatever, you'll probably have to do this. Safer just to raise it now.] Make sure your Master is also up and unmuted, but it presumably is or you'd never hear anything at all.
(b) Edit profile(s) in gnome-terminal and ensure that "Terminal bell" is checked.
(c) gconf-editor: desktop -> gnome -> peripherals -> keyboard. Change "bell_mode" from off to on.
(d) gconf-editor: apps -> metacity -> general. Change "audible_bell" from off to on.

ON EVERY BOOT:
(a) [sudo] modprobe pcspkr [put this in rc.local or somesuch] [Note 1] [Note 2]

ON EVERY LOGIN OR GDM RESTART:
(a) xset b [Note 3] [Note 4]

[Note 0] This will keep your private version of this from being overwritten if a newer version is released. Of course, if a newer version is released that fixes this bug, do "debchange -v 1:2.28.0-0ubuntu1" to declare that what's installed is what used to be installed (this won't -actually- change what's installed) and then update (which will then update it).
[Note 1] If you want the squarewave bell to come out of line-out and not the motherboard beeper, don't bother doing this.
[Note 2] It does -not- work to just comment-out the blacklisting of pcspkr in /etc/modprobe.d/blacklist.conf and reboot; this is because Karmic appears to load this kernel module too early for it to take effect, so you have to wait until the kernel's done loading things and then rmmod it and modprobe it again. Easier (until this bug is fixed) to just leave it blacklisted and just modprobe it in rc.local or in any other init that runs near the end of boot. [Bug #398161]
[Note 3] Every time gdm is restarted, -something- does the equivalent of "xset b 0". (I'd really like to find the guilty party.)
[Note 4] Note also that, due to -another- bug, "xset b 100" does -not- make the volume 100%---instead, it increases the bell -duration-! So "xset b" is a reasonable compromise: it sets the so-called bell volume to 50% and an acceptable duration. [Bug #280767]

P.S. Even once all the actual -bugs- are fixed, I consider the sheer number of places that must be hit to make bells work---e.g., for a rubout at a shell prompt to warn you, or for Emacs t...

[Robert Schroll (rschroll)]

> Confirmed---your patch fixes the issue.

Good to hear!

> Strictly speaking, I don't think you need part 3 of your patch

I this is correct. Part 3 only re-enables the gconf /apps/metacity/general/audible_bell key to turn the bell on and off. Whether metacity *should* have a key to do this, I don't know. But given that it *does* have this key, I think we ought to make it work. Also, I suspect that, without change #3, if this key is set to false when metacity starts, metacity will trap audible bells irrevocably. (I suspect meta_prefs_bell_is_audible() will return False, causing the last argument of XkbChangeEnabledControls() to be 0, which we know will trap the audible bells. But at this point, I don't feel like risking breaking things again to check this hunch.)

> I suspect somebody should open a bug upstream,

I was going to wait a few days to see if WeatherGod can scare up someone from Ubuntu to comment on this patch. I suspect that we'd get a better reception from the Metacity people if we can show this is desired by the Ubuntu project, rather than just a few random cranky users. But it anyone feels like taking the initiative and posting this to metacity's bug tracker before I do, please be my guest!

[Grondr (grondr)]

Yes, I agree re part 3---safer to leave it in as long as metacity claims responsibility. (But it has no business claiming responsibility---leave that to PulseAudio.)

We haven't heard yet about getting this bug punted to the metacity folks, so it may be time take more direct action in letting them know about it...

[WeatherGod (ben-v-root)]

I have flagged down Daniel Chen to take another look at this report, however it is quite low on his priority list and he probably has not looked at it yet. I'll see if I can get someone else to at least mark it as "Triaged".

[Robert Schroll (rschroll)]

Since there's been no action from the Ubuntu maintainers on this, I finally got around to reporting this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=607906 Please take a look and add anything that I forgot.

[Robert Schroll (rschroll)]

I've created a branch of metacity with the changes from the attached patch, and requested a merge with master, as that seems to be what I was supposed to do (https://wiki.ubuntu.com/SponsorshipProcess). For purposes of cross-referencing, here's the merge request: https://edge.launchpad.net/~rschroll/metacity/system-bell/+merge/18357

I've additionally subscribed ubuntu-main-sponsors to this bug. The wiki page on the sponsorship process was unclear as to whether I was supposed to do this in addition to requesting a merge or not. Given the lack of attention so far, I figured it couldn't hurt.

[WeatherGod (ben-v-root)]

Robert, I think that you have gone above and beyond at this point. At least at this point, the maintainers can try out your patches and take a good look at them to see if they want to integrate it. The best bug reports are the ones with patches! Thank you for making Ubuntu better!

[Robert Schroll (rschroll)]

I've edited the description to try to give a better overview of our current understanding of the various problems in this bug. Please add anything I left out.

Also, I nominated this for Lucid because, hey, why not?

[rifter (rifter0x0000)]

Thank you thank you thank you Grondr and Robert for giving some respite to people who are suffering from this horrible bug.

This problem is highly annoying to me. The initial reason for neutering the pc speaker was that besides it being "outdated" you had to grovel through 8 miles of innards to get it to be turned off. Unfortunately the solution resulted in no beep at all (so much for the "outdated" idea -- if it was outdated to have the pc speaker beep why didn't they make a configurable alert sound take over for it?). It also means you have to grovel through 8 miles of innards to get it back on again, and even then it's actually a sad string of hacks designed to turn it back on after the bits put in by the bell-killers turn it off.

When I first ran into this, I thought it was a resurrection of an xterm bug (in version 242, here:

http://invisible-island.net/xterm/xterm.log.html#xterm_243

)that had plagued me in cygwin (which required me to recompile xterm for that platform), but no such luck.

By the way, two whole other sets of directions regarding the bell in ubuntu are here

http://ubuntuforums.org/showthread.php?t=1377990

and

here

http://ubuntuforums.org/showthread.php?t=1377990

I've done everything in the Grondr's comment except for patching metacity, and everything in those two forum threads except for the bit about changing the bell sound. What I don't like is that I have to remember to do

xset b 100

every time I boot up because even though it's in my .xinitrc it doesn't happen. I've put it in my .profile, but that is a hack, and I still haven't rebooted yet to see if that will be sufficient. I should be able to configure the x bell with respect to x, using its init files.

What I have not explored yet, is the probability that the bell is still neutered with respect to the computer's state before X is launched, and regular consoles. Console beeps should work, or at least be configurable in some way.

What would be nice is if you could easily set this without having to grovel through all these places, and whatever you did to do it would undo the things that were done to neuter the bell rather than reacting to them. What would be even nicer is if you could set the bell sound, too. It appears that you can, if you dig deep enough, but at this stage I'm still trying to make sure I have the bell turned on in enough places, and I find more places that it is not and more places where my settings are ignored every day.

Applications that don't speak to sound mixers should be allowed to produce pc speaker beeps, as should the kernel itself. If we are going to try to intercept that, it should be in a way that ensures it will still work, and make both the interception and what we do with it configurable. Likewise, errors made in gui apps and other apps that can speak to the sound mixer should have a configurable sound.

I hope that anyone who is affected by this finds a solution that works for them. Expect to have to wrestle it awhile, and to have a frustrating time going through all these places. I did get my beep to work, I just have to keep turning it back on, and I still worry that there are situations in which the beep is still n...

[Dimitri John Ledkov (xnox)]

I'm part of Ubuntu Reviewers team. Your patch is good to brute-force revert the change but what about people who want both options and switch between the two behavior? As discussed in this long bug report it's not possible yet due to many issues raised and the patch doesn't bring configurable behavior.

I've subscribed foundations team, hopefully they can work on this.

Thank you for making Ubuntu better. This bug sucks indeed.

[Robert Schroll (rschroll)]

Dmitrijs Ledkovs wrote:
> I'm part of Ubuntu Reviewers team. Your patch is good to brute-force
> revert the change but what about people who want both options and switch
> between the two behavior? As discussed in this long bug report it's not
> possible yet due to many issues raised and the patch doesn't bring
> configurable behavior.

The correct way to allow configuration, IMHO, is to use Pulse Audio's module-x11-bell. It can be turned on and off at will just by loading and unloading that module. module-x11-bell is loaded *by default* in Lucid, so it's ready to be used in all it's configurable glory. But metacity traps system bell events and keeps Pulse Audio from seeing them.

This patch would remove this trapping and *allow configuration* through Pulse Audio. It would also ensure that both metacity and compiz use the same system for ringing the bell. It doesn't completely solve the bug, but it gets us significantly closer.

[Robert Schroll (rschroll)]

Just to confirm my previous assertion, I installed the Lucid beta on a virtual machine. I applied my patch [1], restarted metacity, and unloaded and reloaded Pulse Audio's module-x11-bell [2]. System bells rang the same bell.ogg sound file, but through Pulse Audio. Additionally, I could now set the volume with `xset b`. Thus, using this patch would result in the *exact same* behavior as currently exists, except that Pulse Audio is making the noise instead of metacity. Stopping the behavior, to reenable to PC speaker, is now just a matter of unloading the module. Additionally, there are fringe benefits:
1) No delay while metacity loads the sample the first time it's needed.
2) No rate limiting of playback by metacity.
3) Consistent handling of system bell events between metacity and compiz.

Honestly, what more is desired? In several bugs related to this, I have yet to hear a good explanation for why metacity should be handling system bell events. Here's a chance to switch this capability to a more sensible sub-system and solve several bugs or potential bugs all at once. Why are we not jumping all over this? (Sorry to sound shrill, but I'm rather frustrated at this point.)

[1] It didn't quite apply cleanly, but it was easy enough to clean up by hand. I wasn't planning on posting a new patch for Lucid, but if it's desired, let me know.

[2] I don't know why un- and re-loading the module-x11-bell was necessary, but I suspect that it's related to the fact that the old metacity had been trapping the system bell events. I suspect, but haven't confirmed, that this won't be necessary once the new metacity is installed and X is restarted.

[Colin Watson (cjwatson)]

Dmitrijs, metacity is categorised as desktop, as indeed is audio in general - I don't see anything here for the foundations team. I've subscribed canonical-desktop-team and unsubscribed canonical-foundations.

[Robert Schroll (rschroll)]

This was probably unspeakably gauche of me, but I removed the -needswork tag until someone can explain to me why we would want metacity mucking about with the audible system bell events. This bug (and system bell events in general) obviously does still need work, but I just don't see what more is desired for the patch to metacity.

[Akkana Peck (akkzilla)]

A lot of the discussion in this bug has to do with metacity and pulse, but for people who don't use gnome, metacity, pulse or any of that stuff, and just want their pcspkr module to beep when asked under lucid, I just posted a blog article:
http://shallowsky.com/blog/linux/kernel/pcspkr-lucid.html

Basically, I had to un-blacklist it in two places, /etc/modprobe.d/blacklist.conf and by removing the obsolete /etc/modprobe.d/00local that some earlier ubuntu version had put there and upgrades never removed.

[Robert Schroll (rschroll)]

Update for Lucid, for which I'm sure everyone has been waiting with bated breath.

pcspkr is still blacklisted. See the above comment for details.

Metacity behaves the same way as it did in Karmic, trapping all system bell events and using it's own playback capabilities. This is despite the fact that module-x11-bell is loaded by default now. Someone should write a patch for Metacity that would fix that. Oh, wait.

Compiz still doesn't handle system bell events, but now Pulse Audio is set up to handle them, so we get nice-sounding bells in Compiz. At least we would, if the Pulse Audio setup weren't completely broken. In two separate ways:
1) Pulse Audio's module-x11-bell respects the X bell volume, which Gnome sets to 0 somewhere in its startup sequence. (Metacity, of course, ignores this setting. If it isn't in GConf, it doesn't exist.) This was presumably done to shut off the PC speaker beep, but this isn't needed anymore. The volume must be turned up before you could hear anything (`xset b on` or `xset b <percentage>`).
2) As loaded by default, module-x11-bell points to the sample bell.ogg, which doesn't exist! You must either load the sample (`pactl upload-sample /usr/share/sounds/ubuntu/stereo/bell.ogg bell.ogg`) or reload the module with the sample name correctly set (`pactl unload-module <number of module-x11-bell>; pactl load-module module-x11-bell display=:0.0 sample=bell-window-system`).
Now that it's working, you must realize the Gnome's Sound Preferences dialog, which assumes Metacity is running, no longer adjusts the beep sound. (Curiously, the mute button does work.)

But what we REALLY want isn't this high-falutin' boink sound -- we want the PC speaker beep back! When I check previously in the VM, Lucid's Metacity could be patched in the same way Karmic's could. I haven't tried this on my actual machine, as Metacity keeps crashing on me (!?!). But under Compiz, all you should have to do is load the pcspkr module, use `xset b on` to turn up the volume, and unload the module-x11-bell module from Pulse Audio. This turns out not to work -- you also need to start a new instance of Compiz, using `compiz --replace` i.e., for reasons I can't begin to fathom.

This all probably warrants a new bug (or 12). But maybe I'll wait for Maverick, which promises to bring us two new window managers and a whole host of ill-considered mis-configurations. I hope you're all as excited about this as I!

[Akkana Peck (akkzilla)]

A week ago I wrote about un-blacklisting the module. But even with the pcspkr module loaded (lsmod shows it), most of the time there's no beep, either in or out of X. The pcspkr module seems very flaky in Ubuntu kernels. I've never figured out why; if I build my own kernel, pcspkr works fine, whether it's a module or built in. Thought it was fixed in Lucid because it worked once, but I've never gotten it to work again since then.

[Nic Shakeshaft (nshakeshaft)]

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! :)

[Robert Schroll (rschroll)]

Nic, thanks for figuring out that Pulse Audio was the thing breaking the bell in Compiz. I couldn't believe that I should have to restart Compiz to restore the bell, and you showed that I don't.

Armed with this knowledge, I went looking around for where Pulse Audio loads its modules. The X11 ones seem to be loaded in the script '/usr/bin/start-pulseaudio-x11'. The modules and their options are hardcoded (!) here, so I commented out the line mentioning 'module-x11-bell'. Now, the bell beeps appropriately as soon as Compiz starts. (I've not had the problem in bug #398161.) Hooray!

But this doesn't help us with Metacity. The problem there is that Metacity itself is catching bell events and playing sounds itself. There's no way to turn this off short of patching Metacity. I've submitted such patches everywhere I can, and nobody seems to care.

While I'm here, I want to correct two mistakes I made in my previous post. At that point, I was having problems with my video card and window managers were often crashing, so often both Metacity and Compiz had been run in a session. Now that that's fixed and I can run Compiz from session start, I note:
1) The X bell volume (as reported by 'xset q') is 50. Metacity must have been messing with this.
2) There are NO samples loaded into Pulse Audio. This (not a mis-naming) is why the Pulse Audio bell doesn't work by default. Presumably if you wanted the Pulse Audio bell instead of the PC speaker beep you could leave the loading of module-x11-bell in /usr/bin/start-pulseaudio-x11 and add a line that loads an appropriate sample, given the name bell.ogg. But I haven't tested this, because having gotten things working, I'm not messing them up again!

[Thomas Troesch (ttroesch)]

Thank you all for your incredible effort. I have had success with the instructions in these comments.

The system bell is very important for me as well. I have scripts and programs that run when the user is not sitting at the computer or even looking at it, and in a relatively noisy environment. A bell with volume and without lag or rate adjustment is essential for me.

When I get the system bell, I have no control over the volume, and the duration parameter 'beeps' twice as long as xset q would indicate. Is this the same behavior you are getting?

Karmic

cat /proc/version -> Linux version 2.6.31-22-generic (buildd@allspice) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) ) #65-Ubuntu SMP Thu Sep 16 16:21:34 UTC 2010

[Robert Schroll (rschroll)]

On 10/11/2010 11:58 AM, Thomas Troesch wrote:
> When I get the system bell, I have no control over the volume, and the
> duration parameter 'beeps' twice as long as xset q would indicate. Is
> this the same behavior you are getting?

I suspect that this may be related to bug #280767. I've noticed similar problems on my systems, but haven't been bothered to work on them.

[Pete Ashdown (pashdown-xmission)]

This will load the bell.ogg sample for pulseaudio. My guess is that there is some disconnect between the alert settings in "Sound Preferences" and actually doing the load in gnome.

/usr/bin/pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell.ogg

[Michael Vogt (mvo)]

Thanks a lot Robert for looking into this problem and for your patch. I do not feel comfortable enough with the code to judge if that will not have regresions. It would be great if upstream would comment. I noticed that you forward it to the gnome bugzilla (thanks for this). But it looks like upstream is silent on this matter :/

[Chris Halse Rogers (raof)]

The patch looks sane to me (and I've mentioned as much on the upstream bug), but as you've noted it will need some system-integration work to avoid regressions for the people who want their bell to ding rather than PC bleep.

To that end, I brought this up with Luke Yelavich (the main Ubuntu audio guy, TheMuso in #ubuntu-desktop):
...
<TheMuso> RAOF: As for audio this cycle, well I am not entirely sure. I think rodrigo_ is helping out some, and I am spending a little time on bits and pieces here and there, usually package updates, but thats about as far as I know.
<TheMuso> RAOF: IMO PC speaker stuff is disabled and should stay that way, and libcanberra is responsible for sound events.
<RAOF> So the correct way to proceed would be to teach libcanberra to optionally use the PC speaker, and teach compiz to use libcanberra?
<TheMuso> I'd say thats probably the best bet.
...

It would seem to be fairly easy to patch libcanberra to do this, and probably similarly easy to patch compiz to use libcanberra. Luke (TheMuso on Ubuntu IRC, https://launchpad.net/~themuso has email addresses) would be the person to talk to about this design.

[Robert Schroll (rschroll)]

Michael and Chris, thanks for taking a look at this. But I still don't understand why the system bell should be tied to the window manager. It seems to me a strange connection that leads to silly bugs like #430203. IMHO, the obvious solution is to let Pulse Audio handle the beep and leave the window managers out of it. Here's my reasoning:

- Just getting the basics of the proposed libcanberra solution requires writing new code in libcanberra and compiz. In contrast, the basics are already completely implemented in Pulse Audio; we just need to excise some code from metacity.

- The libcanberra solution would require the same code in Metacity and Compiz (and gnome-shell and Unity, presumably). Each would have to be kept consistent with the library. This is not a worry with Pulse Audio.

- I don't know how configuration with libcanberra would work, but it would require some sort of coordination for settings to survive changes in window managers. Pulse Audio keeps running though window manager changes.

- Pulse Audio is a more obvious place for people with audio bugs to start looking.

With Pulse Audio, there is still significant work to be done. Besides patching metacity, Pulse Audio's startup should be altered to make the loading of module-x11-bell optional and to load the appropriate bell sound. Additionally, gnome-volume-control would need it's system bell options rewritten to use Pulse Audio.

Is there something I'm missing that makes having the window managers be responsible for the system bell so attractive? And regardless, should the discussion continue here or in a new bug for "Coherent handling of the system bell"?

[Pete Ashdown (pashdown-xmission)]

>Is there something I'm missing that makes having the window managers be responsible for the system bell so attractive? And >regardless, should the discussion continue here or in a new bug for "Coherent handling of the system bell"?

I think the latter is important, especially on servers that have audio but no window manager. All too often the response to an intelligently set system-bell is "I hate the system bell! How do I turn it off?!?!?" That isn't the point. There are people (myself included) who need a non-obnoxious system-bell to notify them of activity outside their focus.

Does pcspkr only play one waveform? I had more control of my Apple ]['s speaker than I do pcspkr.

[Kees Cook (kees)]

Thanks for the patches and the discussion on this. Can someone from the Ubuntu Desktop team follow this patch through to the end?

[Kees Cook (kees)]

I think until this is fixed in a sensible way upstream, there isn't a safe way to backport fixes to earlier releases.

[Martin Pitt (pitti)]

Being discussed in the upstream bug (where it should be applied first), unassigning.

[Robert Schroll (rschroll)]

Two non-reporter comments, including none from metacity developers, over 13 months may be called many things, but I wouldn't call it "being discussed." Let's be honest - upstream is not fixing this bug. Ubuntu is apparently not fixing this bug. Let's stop misleading people into thinking this will be fixed and mark this as "wontfix" or "dontgiveadamn" or whatever Launchpad's equivalent is.

[Grondr (grondr)]

I'm the original reporter of this bug thread.

I have to say, I'm completely dissatisfied so far. Every proposal has
been to effectively kick this downrange and make it someone else's
problem, and I'm -particularly- unhappy that this is viewed as a
window manager issue! It means the (a) behavior will change for every
different window manager, (b) if I'm not running a window manager,
like I'm in single-user mode or a server, I don't -get- a bell???, and
(c) it seems to imply that a -brand new protocol- must be written and
all the WM's and apps much understand that protocol? What??? It's
not as if just -reverting- the ill-advised changes that broke the bell
literally -years- ago now are getting any developer attention, and now
you propose that someone actually has to write something -new- to get
this fixed? How likely, exactly, is this likely to happen, given that
this issue has now been open for about 18 months now---three entire
release cycles, and obviously not going to be fixed for Natty, so that
means 4 cycles, minimum, or two years.

Kicking it to a WM also has a vey bad precedent---I reported a similar
"this just needs to be reverted" ONE-LINE reversion about libwnck
literally -6 years- ago and which, after -2 years-, the developer
actually agreed -should- be reverted---and then it has sat, for -4
more years-, unreverted. So I can't say that anything whose resolution
is "get the metacity developers to revert this" fills me with glee---my
experience so far is that even things they agree about take literally
years to see any action. (I'm talking about
https://bugzilla.gnome.org/show_bug.cgi?id=171804 here.)
(Surprisingly, about a month ago, it suddenly had some activity on the
bug thread. Maybe it'll get fixed. Maybe. From my outsider's
perspective, just looking at that bug thread, it looks like what had
to happen is that the original developer simply vanished for years and
a couple of people took over in his stead. Is that what's going to
have to happen to get the bell fixed, too?)

So add me to the grumpy crowd that thinks the original change in
behavior was misguided, who think that taking 18 months to get to this
point is way, -way- too long, who disagree that the fix is to continue
to make this the responsibility of the window manager -at all-, and who
wish nobody had ever broken this in the first place---and who cannot
FIX the issue ourselves. All we can do is continue to patch around it
on every release, because a fix must be committed by those who own
this code, and that's not us.

[Thomas Hood (jdthood)]

To re-enable the terminal bell on my ThinkPad X61 running Ubuntu 10.10 I took the following actions suggested above:
    * Un-blacklist pcspkr as described above, then either reboot or modprobe pcspkr.
    * On the terminal window, tick "Edit | Profile Preferences | General | Terminal bell"
    * Run gconf-editor and at "apps | metacity | general" tick audible_bell.
    * Run gconf-editor and at "desktop | gnome | peripherals | keyboard" change "bell_mode" from "off" to "on".
    * Use the alsamixer program to unmute and raise Beep volume to a suitably high level.
    * Do pactl upload-sample /usr/share/sounds/ubuntu/stereo/bell.ogg bell.ogg

Many thanks to the contributors to this bug report!

[Thomas Hood (jdthood)]

Addendum. Even after doing what I just described (above, reply #81), I find that after reboot sometimes beeping doesn't work until I switch window managers between metacity and compiz. :/

[Thomas Hood (jdthood)]

We shouldn't depend on upstream fixing this by removing
behavior that upstream regards as a feature.

It would be nice if upstream made their feature easier to disable.
But we shouldn't wait for them to do that, either, before fixing
the problem in Ubuntu.

[Robert Schroll (rschroll)]

I've filed another bug about problems with the system bell in Unity (#769314). Basically those problems are the same as in Compiz discussed here. So let's talk about Compiz problems over there and keep the Metacity discussion here.

[Pete Ashdown (pashdown-xmission)]

Thomas, I don't think you need to run gconf-editor at all. This is what does it for me on Natty 11.04:

 /usr/bin/pactl remove-sample bell.ogg
 /usr/bin/pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell.ogg
 /usr/bin/xset b on
 /usr/bin/xset b 100

Plug this into a session startup script. Of course it doesn't fix the problem that changing the sound of the bell via "System -> Preferences -> Sound Preferences" has no effect. I can't understand why this continues to be an issue in Ubuntu.

[Thomas Hood (jdthood)]

Pete, thanks for the information.

To summarize what I now know....

There are several separate issues. One is the traditional square-wave
beep function. Many people say that it is necessary to:

  * Un-blacklist the pcspkr kernel module and load it.

However, I have just discovered that this module is not needed on a
Lenovo ThinkPad X61 for "echo 3 > /proc/acpi/ibm/beep" to work.
The latter requires only the thinkpad-acpi module.

Orthogonal to that issue is getting terminal and other bells to
play in the new way, via X, the window manager and pulseaudio.

For the terminal bell to ring, it is still necessary to:

  * enable "Terminal|Edit|Profile Preferences|General|Terminal bell"
  * set gconf setting "desktop|gnome|peripherals|keyboard|bell_mode"
    to "on".

Under natty compiz then the gconf setting
"apps | metacity | general | audible_bell" makes no difference.

Before receiving the tip from Pete Ashdown I was re-enabling the
compiz-managed newfangled audible bell by deselecting and selecting
System Settings|CompizConfig Settings Manager|General|Audible Bell.
This actually enabled the traditional square-wave bell!

But now I see that
  * pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell.ogg
suffices to enable the newfangled bell.

After logging out and in the bell was still enabled without my having
to run xset, but I can imagine it may be necessary to run
  * xset b on
  * xset b 100
under some circumstances.

[Robert Schroll (rschroll)]

Thomas, Pete:

Problems with the system bell are subtle and strongly dependent on what exactly you are trying to do. One of these factors is the window manager. This bug is primarily focused on getting the system bell working under Metacity. gconf twiddling *may* be necessary in this case; Pulse Audio commands will do nothing. If you are trying to get the system bell working under Compiz or Unity, please see bug #769314.

I would have thought the simple fact that the system bell depends on window manager would be enough to convince people that the whole system needs a re-think, but apparently not.

[Luke Yelavich (themuso)]

In a default natty install, the system bell should work in metacity without issue, i.e a system bell is triggered, and metacity calls libcanberra functions to play the system bell sound event.

[Robert Schroll (rschroll)]

> the system bell should work in metacity without issue

Well, except for the issue that we've spent 18 months and 89 comments discussing: You can't turn off the libcanberra bell handling without patching Metacity.

[John Vivirito (gnomefreak)]

This is a problem again. it was working until last week or so. I reinstalled than updated and it stopped working, anything i can do to help with this?

[Robert Schroll (rschroll)]

On 04/17/2012 01:57 PM, John Vivirito wrote:
> This is a problem again. it was working until last week or so. I
> reinstalled than updated and it stopped working, anything i can do to
> help with this?

Your first step should be to determine if this bug is your problem or
not. This bug is specifically about the system bell under the Metacity
window manager. If you're using Compiz (or Unity 3D), see bug #769314.

But in either case, you're pretty much SOL. Nobody seems to want to
even acknowledge that this is a problem, much less think about how to
solve it.

[Aminda Suomalainen (mikaela)]

I am on Lubuntu 12.04 and beep isn't working for me, so I am not getting notifies on highlights from WeeChat with beep script.

I have
1. removed pcspkr from modprobe blacklist
2. modprobed pcspkr
3. rebooted
4. ensured that beep isn't muted in alsamixer
5. I have ran "xset b on" multiple times and have it on my shellrc.

What else should I do? I am using urxvt.

[Anthony (danthonyd)]

Hi all,

It is six years later and this exact problem is back with Ubuntu 16.04 Xenial Xerus.
I unblacklisted pcspkr and loaded the module, plus the overwhelming multitude of other steps.

The "beep" command works and "echo blahblah | wall" also works, "but echo -e '\a'" and "printf '\a'" do nothing, nor does the rubout or other keys in terminal and Gedit.

I've never submitted a bug before, but I'll try now and reference this bug so we can benefit from all your hard work.

[Anthony (danthonyd)]

Okay, I submitted bug #1599599 for the same problem on Ubuntu 16.04 Xenial Xerus.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599599

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alberts Muktupāvels (muktupavels)]

Wontfix.