Comment 13 for bug 486154

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 saying "keys" shows a whole bunch of sound names with either "C.stereo" or "en_us.UTF-8.stereo" in their names, so I fear maybe a locale issue while I was running as root at some point. Doing "dump" shows that ubuntu.bell-window-system.C.stereo points at ...K/usr/share//sounds/ubuntu/stereo/bell.ogg (yes, two slashes), whereas ubuntu.bell-window-system.en_US.UTF-8.stereo points at ...K. Only some of each of the .C/en_US entries have filenames and it's not consistent. There were 46 keys total.

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?)

Your workaround #2 also works for me---after creating the relevant file and having done the rmmod/modprobe beforehand, I get -both- the PA bell.ogg sound -and- the internal speaker for X bell events. (I'd notice a mention of xkbevd when I was reading about xkbbeep, but hadn't tried it 'cause I'd figured that the X bell events were just getting lost. Oops.)

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.

So this shows that there are a whole bunch of bugs floating around that all need squashing:
(a) Unblacklisting pcspkr should just work, dammit, without having to rmmod/modprobe it.
(b) -Something- is stubbornly doing "xset b 0" that I can't find. That's not the default in other releases. WTF? That's yet -another- thing that makes reenabling the bell annoying. (Though see above--maybe something -else- is ignoring the bell volume, which might be the whole damned reason users were complaining so much that the bell got killed!)
(c) Too many separate parts of gnome and PA all have various bells and alerts turned down, and they're scattered all over the UI. The whole thing's a mess. (alsamixer's Bell control; gconf's bell_mode at least; that xset b 0 if that's even doing anything at all; who knows what else I'm forgetting. I know that users complained about an annoying system bell, but the -right- way to have fixed the whole issue would have been to have made that -softer- by default, not smash it in half a dozen unrelated places.)
(d) PA should give a way for users to tell it to -stop- intercepting the X bell! Users shouldn't have to jump through hoops (a-c) -and- also either rename that file or run xkbevd -bg with a config file just to get the bell working again. This is -especially- obnoxious considering that having it intercept the bell is -commented out- by default in /etc/pulse/default.pa and yet it is still being intercepted! (pactl list -does- have an entry for bell.ogg [for me, it's sample #15], but it's not obvious to me that each entry there is "something being intercepted by PA" and it's -certainly- not obvious how to make it stop! As in, its properties say "event" but they -all- say "event", so how does PA know that bell.ogg goes with my system bell? I looked at that list before and assumed the bell was -not- being intercepted because of that; I'm still not sure how to properly interpret that list.)
(e) The PA bell is REALLY slow---it won't fire faster than 1 Hz, and it's delayed. I just discovered (while trying to figure out how PA intercepts it) bug #430203, which claims this has been fixed. Good. But was the 9/22/09 fix too late to make it into Karmic? I'm surprised...
(f) The old X bug where xset percent pitch duration is being interpreted as xset duration pitch duration. C'mon.

I wonder especially about (d). Is this a PA bug? A packaging issue? I'm tempted to report it against PA -and- here and see who gets left holding the bad once all the finger-pointing is over.

(I'd say (b) is a bug because the xset call isn't documented and I can't find who's calling it, and I don't know if it points to a kernel bug with bell volume setting to begin with.)

Anyway, thanks for your help! At least now we both have workarounds, though I'd really like to see this made easier in the future, and I think there are real bugs here. This should not have taken two people a couple of -weeks- to figure out.