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: (a) METACITY??: interception of X bells, forcing elaborate and unsatisfactory workarounds. This is the #1 issue in this bug report and the most annoying. REGRESSION. (b) METACITY: rate-limiting. Possibly fixed by bug #430203. REGRESSION, since the old behavior didn't capture the events & hence couldn't rate-limit if it tried. (c) KERNEL: un-blacklisting pcspkr insufficient, because then it loads too early and doesn't work and must be unloaded and reloaded later by the user. REGRESSION. This is probably bug #398161, but it's current Importance: Undecided, Assigned to Unassigned, so it surely isn't fixed yet. (d) KERNEL??: first bell after a pause gets lost in some cases (see table in attachment). REGRESSION. In those cases, for example, doing sleep 10;echo a;beep;sleep 10;echo b;beep;sleep 10;echo c;beep;sleep 10;echo d;beep;sleep 10;echo e;beep typically beeps ONLY immediately after b and d! a, c, and e are silent! (Although in at least one case, I got a little blip around d.) Also, we have these cases: sleep 10;beep;beep [abbreviated single bell] sleep 10;beep;sleep 1;beep [full-length single bell] [Note this is "beep" and not "xkbbell", though that's worthwhile to test, too.] It all makes me think that something is trying to suppress bells (maybe for rate-limiting?) and accidentally suppresses the -first- bell in a sequence (until maybe 1s has passed) and then "wakes up", when instead it was supposed to be suppressing the -next- one in the sequence. It is PARTICULARLY weird that running xkbevd & killing it again does NOT leave one in the first- bell-missing state that one is in before running xkbevd at all, AND that it's MUCH more common in startx-from-recovery-mode (where most configurations show the behavior) compared to normal boot-into-gdm (where it only shows up on a machine that -has not- run xkbbell since boot). NOTE that this is probably NOT a metacity bug, since my testing from a recovery-mode boot showed that the vanishing bells happen even if X has never run. I doubt that the metacity maintainers are reading this bug; I'm considering opening a bug there and pointing them at this so at least (a) above might get addressed. If someone else does so first, post here so we know. VIEW THIS TABLE IN A FIXED-WIDTH FONT. CONTROL CASE: [hoary/dapper/breezy in gnome] 6 pre-9.XX S3/MB,IM,IN [e.g., motherboard bell works perfectly in all the modes I've tried] USING RECOVERY MODE AND SHELL/XINIT/STARTX: WHERE: X-less shell xinit gnome/metacity g/m w/xkbevd g/m w/xkbevd killed (state) 1 2 3 4 5 BL S1/LO,VA,CN S2/LO,VA,2H --/-- {S2/LO,VA} S2/LO,VA,FU S3/LO,VA,CN [note 1] MO S1/MB,IM,IN S2/MB,IM,2H --/-- {S2/MB} S2/MB,FU,* --/-- {S2/MB} NB S1/LO,VA,CN S2/LO,VA,2H --/-- {S2/LO,VA} S2/LO,VA,FU --/-- {S2/LO,VA} RM S1/MB,IM,IN S2/MB,IM,2H --/-- {S2/MB} S2/MB,FU,* --/-- {S2/MB} DIRECT BOOT INTO GDM (e.g., not using recovery mode and startx): [Note "BB/LO,DL,1H,@" above "S2/LO,FU,@" means they're -both- true, e.g., getting squarewave -and- bong simultaneously.] WHERE: X-less shell xinit gnome/metacity g/m w/xkbevd g/m w/xkbevd killed (state) 1 2 3 4 5 BL BB/LO,DL,1H {S2/LO,VA} BB/LO,DL,1H,@ BB/LO,DL,1H {S2/LO} S2/LO,FU,@ MO BB/LO,DL,1H {S2/MB} BB/LO,DL,1H,@ BB/LO,DL,1H {S2/MB} S2/MB,FU,@ BL = pcspkr blacklisted from boot and never modprobed BX = BL, but "xkbevd -bg" w/appropriate config run Bx = Bx, but xkbevd process killed by hand MO = pcspkr blacklisted from boot, then modprobed later by hand NB = pcspkr not blacklisted, but not rmmod/modprobed, either RM = pcspkr not blacklisted, but then rmmod/modprobed S1 = squarewave bell (~1000 Hz) S2 = squarewave bell (~600 Hz) S3 = squareweve bell (~400 Hz) S4 = squareweve bell (~300 Hz) BB = bong bell -- = silence MB = motherboard beeper LO = line-out so S1/MB is the squarewave bell coming out the motherboard beeper at 1kHz --/-- is total silence {foo} is result of "beep" command; all rest are result of rubout at beginning of line IM = immediate bell DL = bell delayed ~1s on first try; later ones delayed < ~200ms VA = bells completely vanish if > 6 seconds since last one 1H = bell rate-limited to 1Hz 2H = bell rate-limited to 2Hz FU = bell rate-limited to 2Hz, but plays full intervals, even if many already stacked up IN = bell not rate-limited, and interrupts itself (hence not falling behind if lots of them) CN = bell not rate-limited, and plays a solid, continuous tone if many events (e.g., rubout held down) * = "xkbevd -bg" emits a bell the instant it runs---even though there are no typed-ahead attempts at bells... @ = "xkbevd -bg" emits BB/LO -and- S2/MB the instant it runs---even though there are no typed-ahead attempts at bells... xkbevd maybe 600hz, but w/o it, 400hz? NOTE 1: killing xkbevd and logging out, then logging back in (e.g., from startx back to an X-less shell, then startx again), put me back in the g/m state; starting xkbevd again put me in the g/m w/xkbevd state, BUT killing xkbevd left me with NO audio---back in the g/m state, not in the "g/m w/xkbevd killed" state! running/killing it once again didn't change that behavior---still back in the no-audio state when it's killed e.g., states go 3 4 5 3 4 3 4 3 4 ... wasn't able to reproduce this after rebooting. [In MO/1, rubout and "bell" give different bells---rubout is about S1, bell is about S3] sleep 10;beep;beep [abbreviated single bell] sleep 10;beep;sleep 1;beep [full-length single bell] in BB/LO mode, "beep" is S2/LO,VA even though the BB -does not- vanish! doing "sdd if=/dev/sda -onull -bs=1M" simultaneously in a separate shell made no difference to the VA's (I thought maybe the disk was parking, but obviously not while the dd is running).