© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
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.
> 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/
> 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 bunch of bugs floating around
that all need squashing:
> (a) Unblacklisting pcspkr should just work, dammit, without having to
> rmmod/modprobe it.
This is working for me, so I'm guessing it's an issue with your setup or hardware. I would suggest that we ignore this issue for now, or split it out into a separate bug.
> (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!)
But blacklisting pcspkr takes care of this problem, doesn't it? I see no reason why the bell volume must also be set to 0.
> (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.)
I haven't gone around re-enabling the bell in a bunch of places. But my system was upgraded from Jaunty, so maybe I inherited settings from there that kept the bell active. On the other hand, some of those settings you were tweaking may be legacy settings that don't actually do anything now. (But I don't feel like going through and trying each one to find out for sure!)
> (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.
Yes! If we could solve this, I'd be almost willing to put up with all of the other hassles!
> This is -especially- obnoxious considering that having it intercept
> the bell is -commented out- by default in /etc/pulse/
> yet it is still being intercepted!
In fact, it doesn't look to me that module-x11-bell is actually loaded by PA. I can rename /usr/lib/
> (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!
And this sample isn't what's being played for the system bell! Using pacmd's remove-sample, I can get rid of the bell.ogg sample (so play-sample doesn't work), but that sound is still being played in place of the system bell. Huh?!?
> (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...
Judging from version numbers, this fix did make it to Karmic. But the bug report raised three issues: (1) there was silence at the beginning of the bell.ogg file, (2) there is (or may be) a delay in loading the ogg file, and (3) it only repeats at 1 second intervals. The alleged fix only addressed (1). Perhaps we should reopen this bug. (A following post will have a bit more info on the repeat rate.)
> (f) The old X bug where xset percent pitch duration is being
> interpreted as xset duration pitch duration. C'mon.
If it's 4.5 years old, this probably counts as a feature by now....
> 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've changed the bug to Ubuntu's pulseaudio in the hope that someone knowledgeable will be able to do something with it.
> Anyway, thanks for your help!
Thanks for your grunt work in narrowing it down!