[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ding doing nothing
Re: Ding doing nothing
Sun, 11 Jan 2015 14:27:48 +0100
On 2015-01-09, at 22:47, Bob Proulx <firstname.lastname@example.org> wrote:
> Marcin Borkowski wrote:
>> Well, it does not... Maybe I should just live with it (and turn the
>> "visual bell" on).
> There are a lot of reasons why the tty bell might not ring on modern
> computer systems. Sven already noted that it uses the PC speaker.
> Usually that has really harsh binary output audio suitable only for
> very limited noise making. A lot of modern computers don't even have
> a PC speaker these days. It is considered obsolescent hardware having
> been replaced by a sound card with speakers. On several of my
> computers there isn't any PC speaker present. Therefore on those
> systems there can't be a traditional tty bell that rings through the
> PC speaker.
> In addition to the older Linux kernel module pcspkr there is a newer
> module that uses snd_pcsp. On my system in order to prevent the tty
> bell I have to blacklist both of those kernel modules.
> On my Debian Sid system the tty bell is routed through the sound card
> speakers. This uses ALSA. There is an alsa mixer control for Beep.
> In the alsa control it may be muted or unmuted. Try looking for that
> amixer scontrols
> amixer get Beep
> amixer set Beep 50% unmute
> It is possible that you have PulseAudio installed which will override
> all of the audio controls. I won't say anything more other than on my
> system in order to get a working sound system I need to remove PA. YMMV.
> So first I would really check that your system has the hardware
> capability for ringing the terminal bell. It might not.
> On a system with a working terminal bell the following will ring the
> bell in a simple and automatable way. It basically emits ASCII
> character 7 the BEL character. In Emacs every C-g (control-g is the
> ascii 0x7 BEL character) rings the bell. But this can be done in a
> loop while testing and debugging.
> printf "\a"
> while sleep 1; do printf "Ding! \a\n"; done
> As for looking at the bell configuration if you are running X then
> check 'xset q' for bell information. It might be disabled in X.
> On my system:
> $ xset q | grep bell
> bell percent: 50 bell pitch: 400 bell duration: 100
> You mentioned visual bell. If you are using screen then it also
> interprets the BEL character too. If you are using ssh to a remote
> system and screen there then it is still the local terminal that
> handles the tty bell, if it receives the ASCII BEL 7 character.
> I have seen BIOS configurations that allow for enabling and disabling
> the PC Speaker.
> There are so many ways for it to be blocked that it is hard to have a
> single cookbook way of controlling every possibilty. All I can do is
> suggest to get to the lowest level available for debugging and then to
> wish you good luck.
> Good Luck!
Thanks for your input!
Somehow it started to work. Strange.
Anyway, would it be a good idea to redefine (ding) to e.g. fire aplay
with some wav file? I mean: would this work? I guess that if some code
invokes (ding), it would; but what if that code is byte-compiled, for
instance? Should it then be compiled again?
Faculty of Mathematics and Computer Science
Adam Mickiewicz University