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. -- System beep broken in Karmic despite heroic efforts to fix it https://bugs.launchpad.net/bugs/486154 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
