The command 'beep' does not produce a sound

Bug #144022 reported by Detlef Lechner
54
This bug affects 10 people
Affects Status Importance Assigned to Milestone
beep (Debian)
Fix Released
Unknown
beep (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Ubuntu 7.04 kernel 2.6.20-16-generic
man beep writes: "While it can be run quite happily on the command line, it’s intended place of residence is within shell/perl scripts, notifying the user when something interesting occurs... All options have default values, meaning that just typing ’beep’ will work." But this is not the case with my laptop computer MD97600.
Issuing the command 'beep' in a Gnome terminal or in a console does not produce anything.
root@MD97600:~# /bin/echo -e '\a' in a Gnome terminal produces an empty line and a short vibration of the terminal window but no sound.
root@MD97600:~# aplay /usr/share/sounds/phone.wav , issued in a Gnome terminal or in a console, produces the text
"Wiedergabe Wave '/usr/share/sounds/phone.wav' : Signed 16 bit Little Endian, Samplingrate: 44100 Hz, Stereo" and a pretty bell sound.
^G in a Gnome terminal only produces a vibrating window but no sound.
Gnome main menu System > Preferences > Sounds > System beep > Assert system bell is asserted.
The command softbeep in terminal produces no sound but prints 'Spawning subshell.'
The command softbeep >2/dev/nul in terminal produces no sound but prints 'Spawning subshell', an empty line and waits for further input.

Revision history for this message
Luke Yelavich (themuso) wrote :

This is more than likely a hardware configuration issue. You should check your mixer settings to ensure that the volume for PC speaker is not muted, and is turned up, if possible.

Changed in beep:
status: New → Invalid
Revision history for this message
Detlef Lechner (detlef-lechner) wrote :

alsamixer does not show an entry 'PC speaker'.

Revision history for this message
Detlef Lechner (detlef-lechner) wrote :

The problem persists in Ubuntu 7.10.

Revision history for this message
Henri (henrip) wrote :

There is Debian bug 354694 for this, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354694

Problem is that pc-speaker event device is not on event0. It may change depending other event devices.
So easy way to fix problem is to use beep command:
  beep -e /dev/input/by-path/platform-pcspkr-event-spkr <other parameters>

I hope beep package maintainer will change default device from /dev/tty0 to this /dev/input/by-path/platform-pcspkr-event-spkr
I don't know if alsamixer has anything to do with this. I have understood that alsamixer and pc-speaker is only when internal speaker is connected to audio-card input.

Problem can be reproduced when /dev/input/by-path/platform-pcspkr-event-spkr is not pointing to /dev/input/event0 and then run command beep.
Running: strace beep you'll find errors something like this:
  open("/dev/tty0", O_WRONLY) = 3
  ioctl(3, 0x8000451a, 0x2ace0bbef0f8) = -1 EINVAL (Invalid argument)

Revision history for this message
Henri (henrip) wrote :

Problem still exists if pc-spkr is not on /dev/input/event0.
Workaround is to run command: beep -e /dev/input/by-path/platform-pcspkr-event-spkr

Changed in beep:
status: Invalid → Confirmed
Changed in beep:
status: Unknown → Fix Released
Revision history for this message
Rhonda D'Vine (rhonda) wrote :

 Is this bugreport assigned to the wrong package? It speaks about softbeep which is a completely different thing?

 Anyway, if it is about beep it should be closed with the usage of the -e switch. The program is not meant to be that unversal and guessing everything on its own, that would just bloat it to at least double the size it has, codewise, and people would still complain about it not work in some special corner cases...

Revision history for this message
Detlef Lechner (detlef-lechner) wrote :

The problem persists in Ubuntu 8.04.
"detlef@MD97600:~$ uname -a; Linux MD97600 2.6.24-19-generic #1 SMP Wed Jun 4 16:35:01 UTC 2008 i686 GNU/Linux."

'apropos platform-pcspkr-event-spkr' does not produce any output.
@Gerfried: Please read the description which Synaptic provides. This description defines the functionality of the beep command clearly.

Revision history for this message
Rhonda D'Vine (rhonda) wrote :

Detlef, I've written the description of the package myself, so no need to tell me reading it :)

The description doesn't claim that it will work without using of any commandline option on all systems - that was the main purpose for introducing the -e switch. It's not a "workaround" like Henri likes to call it, it is the expected behavior.

 Maybe switching from probing /dev/input/event0 to /dev/input/by-path/platform-pcspkr-event-spkr might be someting to think about, though that would limit its usage to udev using systems, which I would like to avoid.and would propably turn into a regression.

If you say that platform-pcspkr-event-spkr doesn't produce any sound for you neither - do you have that symlink at all? Does PC speaker beeps like shell backspace in the first character or similar beep for you? If not it's not a beep problem, you should get pc speaker beeps working at all for a start.

Revision history for this message
Emmet Hikory (persia) wrote :

I'm marking this bug "Invalid" at the request of the Debian Maintainer. This behaviour is the expected behaviour of beep when in an envronment which requires access to event0, and -e should be used in that case.

Changed in beep:
status: Confirmed → Invalid
Revision history for this message
Mysha (mysha) wrote :

This isn't Debian. This is Ubuntu. If the configuration isn't expected to configure it into a working state for Ubuntu, then the documentation should tell the user how to solve that. And I do hope this will be configurable once, instead of figuring out what device to use every time we want a beep.

Changed in beep (Ubuntu):
status: Invalid → Incomplete
Revision history for this message
Rhonda D'Vine (rhonda) wrote :

 I don't understand what you mean with respect to "This isn't Debian. This is Ubuntu." That response somehow doesn't make much sense to me.

 About the configuration into a working state - please read the linked bugreport in Debian about that the other approach also was giving quite some people troubles, so it was reverted back.

 About having it configurable, this won't happen. beep is a ~250 line C program. Adding the complexity of a configuration file would outweight the benefit by far.

 Thanks for understanding.

Changed in beep (Ubuntu):
status: Incomplete → Won't Fix
Revision history for this message
Daniel Richard G. (skunk) wrote :

Hi Gerfried,

Regarding something you had said earlier:

> Maybe switching from probing /dev/input/event0 to /dev/input/by-path/platform-pcspkr-event-spkr might be someting to think about, though that would limit its usage to udev using systems, which I would like to avoid.and would propably turn into a regression.

The program already does a two-step fallback in a normal invocation (/dev/tty0, then /dev/vc/0, the latter of which doesn't even exist on my system); it seems like a three-step fallback with the udev path tried first would make sound more probable, without bloating the program or making it break in certain system configurations.

As it is, the documentation doesn't explain what an "event device" is, and only gives the examples of /dev/tty0 and /dev/vc/0, which at best gives the hint that "event device == terminal device". Anything under /dev/input/* is going to seem like a non-sequitur to all but the most technical users. Requiring the user to specify -e with an appropriate device is a fairly tall hurdle for a program whose sole purpose is to make a beep.

Moreover, given that the program is meant to be used in scripts and such, requiring -e becomes a bit cumbersome---if you don't want to give it literally with every invocation, you have to stick it into a variable, or wrap up the invocation in a function/subroutine, etc. And then if you want the same script to work on different systems....

Perhaps the best point in favor, however, has to do with the strange situation currently surrounding the pcspkr module in Ubuntu. In a stock install, the module is blacklisted, because many users hate the old-school beeps. If you comment out the blacklist entry, the module is loaded, but you still don't get ordinary terminal beeps---you have to unload and reload the module a second time in order to get the classic behavior (see bug #398161). The reason for this is still unknown, and there's obviously not a whole lot of interest in getting an answer.

What's interesting here, however, is that on a system with pcspkr loaded, but nonfunctional terminal beeps, "beep -e /dev/input/..." works. ("beep" by itself does not.) Having the program try the udev path first would be advantageous in that the program's success then depends only on whether the pcspkr module is loaded, and not on whatever weird issue is affecting terminal beeps. Their problem is no longer your problem.

Revision history for this message
Magnentius (nieuwsgroep222) wrote :

I wish to state that this problem persists in Ubuntu 10.04. "beep -e /dev/input/by-path/platform-pcspkr-event-spkr" doesn't work, even when I added "rmmod pcspkr || true / modprobe pcspkr || true" to /etc/rc.local and rebooted. (See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/398161). It's very annoying because beeping is an essential part of my bash scripts as a notification to the user and I don't know of any alternative, except playing something with totem, which isn't an ideal solution.

Revision history for this message
Ha-Duong Nguyen (cmpitg) wrote :

I can confirm Magnentius's comment (#13). Recently, I have written some scripts which need Ubuntu's beeping feature. Neither Ubuntu's beep package nor Perl's Audio::Beep works. The workaround from Henri's comment (#5) did not work. I'm using Ubuntu 10.04

Revision history for this message
Lucian Adrian Grijincu (lucian.grijincu) wrote :

Stil present in Ubuntu 10.10.

Revision history for this message
bobemoe (bobemoe) wrote :

I thought I was experiencing this problem, but all I had to do was modprobe pcspkr and then beep works without specifying device or any other arguments.

Ubuntu 10.04 64bit

Revision history for this message
san_ubuntu (gupta-sandeep) wrote :

Faced same problem with 10.10 and bobemoe solution also works 11.04

Revision history for this message
Alexander (lxandr) wrote :

For me the problem was in ALSA, snd-hda-intel module.

$ modinfo snd-hda-intel | grep beep
parm: beep_mode:Select HDA Beep registration mode (0=off, 1=on, 2=mute switch on/off) (default=1). (array of int)

So, "modinfo" says that "beep" sound can be manipulated through "beep_mode" module parameter.
By default it is "1", but it's not working.

I've modified /etc/modprobe.d/alsa-base.conf:
...
options snd-hda-intel power_save=10 power_save_controller=Y index=0 beep_mode=1
...

Now after reboot pcspeaker works!

I think that this solution may help only for those who uses integrated audio card (when "beep" sound is produced through audio card).

My config:
Ubuntu 10.10
2.6.37-12-generic #26-Ubuntu SMP Wed Jan 5 18:38:48 UTC 2011 x86_64 GNU/Linux

$ lspci
...
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
 Subsystem: Hewlett-Packard Company Device [103c:30c2]
 Flags: bus master, slow devsel, latency 64, IRQ 16
 Memory at 84000000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: <access denied>
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel
...

Revision history for this message
Bjørn Panyella Pedersen (bjopp) wrote :

Same problem (no beep) here using kubuntu 10.10 (Linux golem 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 18:42:20 UTC 2011 x86_64 GNU/Linux).

Everything worked fine in 10.04. I fixed the blacklist issue noted by That Bum (https://answers.launchpad.net/ubuntu/+source/beep/+question/130004) and rebooted but it did not help. Alsamixer shows beep to be unmuted and at full volume. Beep runs without errors but no sound.
Also tried 'modprobe pcspkr' as suggested by Bobmoe (https://bugs.launchpad.net/ubuntu/+source/beep/+bug/144022) to no avail.
running 'lsmod | grep pcspkr' shows pcspeakers are loaded.
running 'rmmod pcspkr' and 'modprobe pcspkr' reloaded pcspkrs but does not help.

Revision history for this message
Bjørn Panyella Pedersen (bjopp) wrote :

This now works for me using the solution from post #18.
Thanks Alexander (& Mannex (https://answers.launchpad.net/ubuntu/+source/beep/+question/130004) for pointing out that this solution now works)!

I tried this in 10.10 without success, but retrying now in 11.04 fixes the problem.
Currently running:
Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
beep-1.2.2

Revision history for this message
helpdeskdan (helpdeskdan-gmail) wrote :

Simple modprobe pcspkr worked great for me in 12.04. Add to /etc/modules and good to go. No -e required - much thanks for the tip.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.