Comment 27 for bug 486154

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 like this keep the workarounds from rising to the level of solutions.

> We're just flailing here---someone who knows the codebase could
> probably fix all of these random bugs in short order,

Amen.