Use proper sound event instead of system beep

If I blacklist the pcspkr device in /etc/modprobe.d/blacklist, things are a little different:

No beep (or system alert sound) plays anymore, even with "play alert sounds" checked. Even clicking the little play buttons no longer plays the sound (neither beep nor the audio file). There is no more annoying beep on shutdown either.

Yes, this beep is extremely loud. It's not only annoying, it really hurts in ones ears. For example: When someone hears music over his earbuds and Evolution finds a new mail the alert sound is triggerd and produces an extremely loud beep direct into his ears ... really hurting, annoying and shocking.

Is this maybe a problem with pulseaudio not controlling the pc speaker?

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

Seb, this bug is still about a very open (and very annoying) issue, but the bug you've linked it to has all its tasks marked invalid; and seems to be about multiple issues. I think it'd be better if we kept this one open and pointed the other bug here.

I confirm this bug for Intrepid.
Gnome doesn't play any Alert Sound when everything is checked in system->preferences->sound.

I have my internal pc speaker unplugged (because I hate it) but still have the mod active:
$ lsmod | grep pcspkr
pcspkr 10624 0

I was looking for a way to have gnome make the beep sounds (that would be nicer than an internal speaker!): here's the question I posted in launchpad (for references):
https://answers.launchpad.net/ubuntu/+source/gnome-control-center/+question/58158

gnome-control-center:
  Installé : 1:2.24.0.1-0ubuntu7.1
  Candidat : 1:2.24.0.1-0ubuntu7.1

I am seeing this problem on Jaunty, and it is *EXTREMELY* annoying (even more annoying than people who feel the need to write in all caps). I'm surprised my ear drums have not burst yet (I'm not kidding). This sound is what I imagine I would hear if I were to stick my tongue into a 240V socket, except that might hurt less.

This same laptop worked fine with Intrepid and Hardy. All other sound seems to work, but I don't dare use it for fear the system might decide to beep. Please let me know what information might be useful.

there is different issues there, the beep should not be that loud and reboot should not trigger a beep but none of those are gnome-control-center issues

there is different issues there, the beep should not be that loud and reboot should not trigger a beep but none of those are gnome-control-center issues (rebooting using the command line does the same sound), the capplet should still have an option to choise not using the beeper though

This also happens to me with a Dell Latitude D830.
I upgraded to Jaunty and whenever the PC Speaker is supposed to play this very annoying sounds plays... nothing close to a normal pc speaker!
I've tried "rmmod pcspkr" which makes the sound come less often but still every few minutes when I do "something wrong".
Changing sound volumes does nothing to the sound.

If I reboot to the Intrepid kernel this problem goes away.

BR Gunnar Steinn

@Gunnar - As this seems to be a couple of bugs you may want to look at Bug #331589. No solution, but you may want to subscribe.

In Jaunty, when I use the applet to disable the system alert, the pc speaker beeps (from eg the terminal) stop. But when I enable them, the pc speaker plays instead of the nice Gnome sound that I can hear if I hit the play button in the applet.

pitti - could you please take a look and see if you know what the right package is?

To eliminate lower layers in the audio stack as culprits, you should attach output from running http://www.alsa-project.org/alsa-info.sh. This should be required for all audio bugs.

Make sure you also check the streams under pavucontrol to see they're being sent to the correct sink (if you have the pc speaker listed as a sink).

Daniel, here's the output of alsa-info.sh: http://www.alsa-project.org/db/?f=b51c0521b6302c0ed1bef4fcd755426f98d03a33

If I run pavucontrol all I see are system sounds for playback and HDA Intel ALC 268 Analog for playback devices. Pressing mute on either (or both) doesn't stop the beeps.

Fwiw, I see exactly what Scoot sees (err... hears) on Jaunty. A very harsh, loud beep instead of the pleasant sound from the theme:
http://www.alsa-project.org/db/?f=b93fbbb2e5dcf9271d4b078ca1b4abd99b6b854d

However, I can use System/Preferences/Sound and uncheck 'Play alert sound' on the Sounds tab to completely silence it.

Forgot to mention this is on an up to date Jaunty as of a couple days ago.

I have these pc-speaker beeps too.
They happen when I suspend my laptop and when it is woken up.
http://www.alsa-project.org/db/?f=20f967f474ceec45ab700ab4414b615405e8426c

I cannot silence it with System/Preferences/Sound properties.

Yep, just acquired my first Linux machine this week - a System76 Pangolin Performance - these beeps are startling!

I, too, was able to un-check the "Play alert sound" and have relief from the obnoxious, angry beeping (each time I backspace one-too-many-times)

Being new to Linux & Ubuntu... all of the computer jargon above is like a foreign language to me... but I'm guessing that there is no "real" solution to the problem, other than un-checking the aforementioned box? I'm not sure if I am running "Jaunty" or "Intrepid" .... as a matter of fact, I have no clue what these names are describing...

Lastly, the "help" option available to the sound properties dialog box was not at all helpful. It did not seem to relate in any way to the dialog box with which I was interfacing. Seems like this is mentioned above a few times, and so... I concur!

Bug 331589 is the part which uses the PC speaker on random events, like in gnome-terminal (which can be influenced by GNOME) and system shutdown (which is outside of GNOME). This one will be fixed for Jaunty (fix committed already).

I leave this for the "does not use nice pulseaudio X11 sound".

the audible_bell gconf key and settings are handled by the wms and not by gnome-control-center

one easy workaround would be to change the audible_bell default to false in the gconf default

If it is a wm problem then it's also a metacity problem since I have desktop effects disabled.

Wishlist? No, I think we've lost sight of what issue this bug refers to. I'm not terribly sure it's been assigned to the correct packages, either.

In multiple applications, in both metacity and compiz, the computer acts as old computers did when you had no sound card; there are no nifty wav (mp3, ogg, whatever) sounds played, the computer only plays a beep. I'm not sure where the problem lies. We've had confirmation that this happens in transmission, firefox, gnome-terminal and in the GTK+ demo application as well. No one (that I've seen) has confirmed this bug in KDE or any other desktop environment (xfce, openbox etc) than gnome. I find it hard to believe that this is an identical bug in metacity /and/ compiz- it seems more like a setting or library both of them draw upon, like pulseaudio or alsa or the audio system somehow- maybe something gnome related. Regardless (it may be a bug in both compiz and metacity for all I know) this is certainly not a wishlist it is a bug, and a reproducible one at that. A file is set as the default alert sound in the gnome control center sound panel, yet that sound doesn't play, and neither does the selected shutdown sound. I'm not sure why this was changed to a wishlist item.

I'm going to give appropriate parties from compiz and metacity (who should be subscribed to this bug) a few days to correctly triage this bug before I set it to confirmed in both compiz and metacity, with importance low (since I'm not one to define priority for other developers). From what I understand of bug triaging, wishlist is for adding non-critical features, not for categorizing when a program fails to act as advertised.

For those looking to turn down the volume of or disable the beep altogether, browse the comments of the duplicates of this bug - that has been addressed elsewhere. You can usually find a mixer slider for your speaker sounds and turn that down or mute it completely. The fact that the beep is too loud by default is a completely different bug which has been filed elsewhere, please excuse me for not remembering exactly where or finding it for you right now. I'm just hoping this bug report gets in front of the right people, which I don't think it has yet.

It's marked as wishlist for compiz because it is a request to change a default setting. However, that setting actually seems to have no effect as I don't get an alert sound or a system bell no matter what combination of options I select.

I experience the same as travis does. Ticking various options on/off does not help for me.

I had sound on a laptop that worked flawlessly (as I experienced) in intrepid, and upon installing jaunty, this behavior appeared. All of the solutions I've seen proposed are not fixes for this bug; blacklisting the pc speaker module, controlling the volume of the pc speaker in a mixer.

This bug is the following: I can set an alert sound to be played, I can pick an mp3 or wav in gnome-control-center, and upon triggering the alert sound, all I hear is a beep. I assumed that this is some sort of fall back behavior for when sound isn't installed or configured properly, especially considering, and here's the kicker, that I get absolutely no warning or error message from ubuntu upon trying to select an alert sound. As far as a user is concerned, their audio is working properly (I could still play music from rhythmbox, for example), but for a completely unknown reason, the alert sounds just don't play.

There are many duplicates for this bug which propose blacklisting the pc speaker or other such 'workarounds' or 'fixes' for this bug, none of which explain or address why my audio works in some applications, but some part of my system fails to play the alert sound.

If someone wants to point me to the bug where this issue is actually being addressed, maybe I'm in the wrong place. Every duplicate I can find, linked to this bug or not, all has the same 'resolution' listed, involving the pc speaker mixer or blacklisting the module completely, and to me, that is not a resolution for this issue. I've been attempting to coral all the users who are experiencing this issue to the same bug report, so that the developers can pin down why this happens, or at the very least explain that it's a fallback behavior, and that it can be caused by any number of issues with the user's installation, which have to be addressed one by one. Right now we have a default install of the ubuntu OS that leads users to believe that their audio is working, but gives them no indication or error message as to why it wont play their selected shutdown or alert sounds (among others?). To me that sounds like a bug. As I said before, I'm not even sure this bug has been assigned to the proper packages or projects. To me it seems highly unlikely that metacity and compiz suffer from the same exact issue and have the same exact fall back procedure. I haven't seen a single definitive response from anyone, developer or not, that explains when and why ubuntu chooses to play a beep instead of the alert sound defined in gnome-control-panel.

I'm having this system sound problem not only in Ubuntu 8.10 and 9.04, but also in Opensuse 11.1 and Fedora 10. However only Ubuntu plays the system beep instead.
In 8.10 I could solve the problem with installing a newer version of libcanberra using this guide:

http://www.ubuntugeek.com/howto-enable-system-sound-in-ubuntu-intrepid.html#more-1028

In 9.04 this was not working the last time I tried.

I have also tried the live CD of the current test version of 9.10 and I didn't hear any system beeps but the shutdown sound still didn't play.

@michael perigard: thanks for your insightful comments - blacklisting pcspr pretty much obfuscates the issue.

However, neither metacity nor compiz are the issue. Using KDE, I'm using neither of those; but Firefox keeps beeping (not that I have an issue with the beeping itself - but it should honor GNOME settings). The beep is caused by using XkbBell() (you can trigger that by simply calling xkbbell binary). GTK uses this from gdk_display_beep() and gdb_window_beep(). GNOME uses that from who knows where. So this is entirely a GTK/GNOME issue. Run a debugger on the program that keeps beeping, set a breakpoint on XkbBell(), and run. When the breakpoint is hit, the backtrace tells you what precisely needs to be fixed.

This is the solution to make pulseaudio produce a themed beep instead of the system beep:

$ pactl load-module module-x11-bell sample=bell.ogg

I haven't had to do this manually before, but something broke in my Karmic installation a week ago or so. I have no idea whose responsibility it normally is to get this information into PA.

It seems that metacity now uses libcanberra so it works around the issue but pulseaudio should be loading module-x11-bell for other WMs and for things the WM can't control.

Actually it seems running that pactl command is not enough to make the beep work with compiz anymore. Not sure what is going on there.

Also, I've left this bug open against compiz because compiz should use libcanberra for this too.

This bug was fixed in the package pulseaudio - 1:0.9.19-2ubuntu1

---------------
pulseaudio (1:0.9.19-2ubuntu1) lucid; urgency=low

  * Merge from Debian unstable, remaining changes:
    - epoch (my stupid fault :S)
    - Don't build against, and create jack package. Jack is not in main
    - use speex-float-1 resampler to work better with lack of PREEMPT in
      karmic's -generic kernel config, also change buffer size
    - Add alsa configuration files to route alsa applications via pulseaudio
    - Move libasound2-plugins from Recommends to Depends
    - Add pm-utils sleep hook to suspend (and resume) users' pulseaudio
      daemons
    - Make initscript more informative in the default case of per-user
      sessions
    - add status check for system wide pulseaudio instance
    - create /var/run/pulse, and make restart more robust
    - LSB {Required-*,Should-*} should specify hal instead of dbus,
      since hal is required (and already requires dbus)
    - indicate that the system pulseaudio instance is being started from the init
      script
    - Install more upstream man pages
    - Link to pacat for parec man page
    - check whether pulseaudio is running before preloading the padsp library
    - Add DEB_OPT_FLAG = -O3 as per recommendation from
      pulseaudio-discuss/2007-December/001017.html
    - cache /usr/share/sounds/ubuntu/stereo/ wav files on pulseaudio load
    - Generate a PO template on build
    - add special case to disable pulseaudio loading if accessibility/speech
      is being used
    - the esd wrapper script should not load pulseaudio if pulseaudio is being
      used as a system service
    - add a pulseaudio apport hook
    - fix some typos in README.Debian
    - drop padevchooser(Recommends) and pavucontrol (Suggests)
    - drop libasyncns-dev build dependency, its in universe
    - add libudev-dev as a build-dependency
    - Fix initialization of devices with modem subdevices
    - Backport ALSA BlueTOoth position fixes from git HEAD
    - Disable cork-music-on-phone
    - Revert sse2 optimizations
    - disable flat volume
    - Handle div by zero attempts
    - Mute IEC958 Optical Raw by default
    - use tdd instead of gdbm
  * debian/control:
    - Dro packages, due to debian including the files in these packages in the
      main pulseaudio package: pulseaudio-module-udev,
      pulseaudio-module-udev-dbg, pulseaudio-module-rygel-media-server,
      pulseaudio-module-rygel-media-server-dbg
    - Add conflicts/replaces for pulseaudio-module-udev and
      pulseaudio-module-rygel-media-server
    - Add replaces for pulseaudio-module-hal to the pulseaudio package to handle
      upgrades from hardy
    - Remove rtkit from conflicts, and add it to recommends, as 2.6.32 has the
      needed patches

  [ Daniel T Chen ]
  * 0057-load-module-x11-bell.patch: Load module-x11-bell in the
    start-pulseaudio-x11 script (LP: #301174)

pulseaudio (0.9.19-2) unstable; urgency=low

  * Built with normal old-style hal support on kfreebsd and the hurd
  * debian/patches/0001-Work-around-some-platforms-not-having-O_CLOEXEC.patch:
    + Added. Don't use O_CLOEXEC on platforms that don't support it.
      (Closes: #5508...

I have no idea how I had access to change the status of this bug ! I couldn't change it back to triaged, so I just changed the status to In Progress.

Myself, I am still trying to get compiz to sound the nice bell that metacity does on a beep.

On up-to-date Lucid, there's still no system bell with compiz enabled for me.

I also experience it on current Lucid.

Could anyone post some recent reproducing steps, somewhere in plain Lucid where the should should appear?

Steps to reproduce on up-to-date Lucid on amd64 (Thinkpad X200s):

- System->Preferences->Sound->Sound Effects: Alert volume is at 100%, sound theme is "Ubuntu", alert sound is "Default", "Enable window and button events" is unselected.
- System sound is not muted, volume at some reasonable level (50% in my case).
- System->Preferences->Appearance->Visual Effects: Select "None", click "Close"; Window manager is metacity.
- Open Gnome Terminal: Edit->Profile Preferences->General: "Terminal bell" is selected. Click "Close".
- In the terminal's window, hit Backspace on an empty prompt. The system alert sound is played as expected.
- System->Preferences->Appearance->Visual Effects: Select "Normal", confirm the pop-up, click "Close"; window manager is Compiz.
- In same gnome-terminal window, empty prompt: Backspace produces no sound.
- System->Preferences->Appearance->Visual Effects: Select "None"; window manager is metacity again.
- Alert audible again.
- BTW, there's a compiz process still running even after the switch back to metacity: "/bin/sh -c /usr/bin/compiz-decorator".

Same problem same steps to reproduce as dimitris (alert sound without Compiz, with Compiz no alert sound after reboot)
System: Lucid 32 Inter core 2 duo acer Aspire

In natty, Compiz plays a sound for the beep (e.g., the terminal bell) if you do this first:

* pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell.ogg
* xset b 100

I have added these commands to my ~/.xprofile script.

Great! Thank you Thomas.

I have since discovered that it is necessary to put

    pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg

in ~/.xprofile, and

    xset b 100

in ~/.bashrc.

Hi, is this reproducible in recent supported versions of Ubuntu?

To reproduce in 12.04.1 with Compiz:

IIn Unity System Settings/Sound, Sound Effects tab, Alert Volume to a reasonable level, Mute not selected. Output volume to a reasonable level, Mute not selected. Click between various alert sounds, verify that you can hear them. If not, troubleshoot audio output before continuing.

In Compiz Settings Manager, Generall Options plugin, General tab, Audible Bell enabled.

n gnome-terminal default profile, General tab, enable "Terminal bell". At a shell prompt in the terminal window, hit backspace--no sound heard. Execute "beep" command with no parameters--no sound heard.

The workaround in Comment 41 did not change this behavior for me.

Still reproducible in 13.04, out of the box install. (everything default)

The workaround shown in #39 and #41 still works, though I think it uses the wrong sound file. I use this, for the default bell sound:
    pactl upload-sample /usr/share/sounds/ubuntu/stereo/bell.ogg bell.ogg

IIRC someone once wrote a Sound plugin for Compiz, where sounds could be assigned to various system events.
I'll try to find it and investigate in which state it is...