System bell completely silent because PulseAudio sample file undefined by default

I believe this is an amalgamation of bug #486154 (bad pcspkr beep integration with pulseaudio, roughly) and bug #537703 (pulseaudio bell not triggered from compiz). I'm not sure if you add anything else - you may want to flag this as a duplicate of one of the others, or to specify more clearly what it is exactly that you want fixed.

Thanks for the fast reply. As I note in this bug and in bug #486154, that bug is primarily focused on the system bell in Metacity. We did uncover problems under Compiz, but I thought it would be better to split them out into their own bug. This is that bug. Hopefully, unlike #486154, this one is solvable.

Thanks for bringing #537703 to my attention. I remain firmly of the position that Compiz is behaving exactly correctly - window managers should not be mucking about with audio. This is why I specifically did not file this bug against Compiz. I will let #537703 know about this bug, and if they believe a solution to this one is a solution to both, then we can mark one as a duplicate. But if they're looking for a fix to Compiz, then these need to remain separate.

> specify more clearly what it is exactly that you want fixed.

I would like a sensible default for handling the system bell that is easy to customize. We need to decide what that default is before we can figure out what needs to be fixed. This is my attempt to get the relevant parties together to make that decision.

Doesn't seem to be a Unity bug. Can be reproduced in a Classic Desktop environment as well.

The same problem does exist in Ubuntu Classic/Compiz, though not in Ubuntu Classic/Metacity. (I had been unaware of the Compiz variant until you pointed it out.) As this is an integration problem, I thought the desktop environment would be a good umbrella organization to organize the response. Is there some "desktop experience" project that would be a better fit?

Symptoms look identical to bug 301174. Also, FWIW, the sound preferences tab fails to control volume, but does control muting, of the alert sound after the manual xset and pactl steps from the description are followed.

up to date Natty on Thinkpad, default Ubuntu sound theme.

The problem is that compiz does not have anything that talks to libcanberra to play a sound event. The solution here is to write a compiz plugin that listens for the system bell event, and calls libcanberra. I intend to try to put a plugin together in the near future, but if someone beats me to it, I won't be bothered.

I'm afraid I still fail to see why the correct solution here is to produce duplicate code in each window manager instead of letting the sound system handle it. But if we must add this functionality to Compiz, please please please give it an off switch.

Thanks.

> 5) gnome-volume-control doesn't.
> The "Sound Effects" tab of gnome-volume-control
> offers to set the volume and sound for system bell
> events, but these have no effect. This is because
> gnome-volume-control is trying to control system
> bells through metacity. Ideally, it should be rewritten
> to control module-x11-bell instead, but a temporary
> fix could be to simply disable this tab.

In natty, on the Sound Effects tab there is no control for system bell events. So this part of the report seems fixed.

FYI, on a fresh natty install, as a workaround, to enable beeps (e.g., terminal bells) permanently I created a ~/.xprofile file with:

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

> In natty, on the Sound Effects tab there is no control for system bell
> events. So this part of the report seems fixed.

I just updated my Natty VM, and the Sound Preferences dialog still has a "Sound Effects" tab that offers to set the alert sound and volume. I just created a new user, and he has it too, so it's not some hold-over from a previous configuration. Could you have changed some settings to hide this?

Yes, there is an "Alert volume" slider with "Mute" button. I didn't realize that you were referring to this when you said "system bell" --- I didn't know that they were the same thing. My apologies. It's true that this slider has no effect on the volume of the sound that gets played when the workaround ("pactl upload-sample..." and "xset b 100") is applied.

Regarding the workaround, I have since discovered that "pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell.ogg" has to go in ~/.xprofile and "xset b 100" has to go in ~/.bashrc.

On my laptop the bell is also getting muted upon resume.I had to make following /etc/pm/sleep.d script to override that:
case "$1" in
  resume|thaw) { sleep 5; DISPLAY=:0 xset b 100; } & ;;
esac

Is there any more elegant solution for that?

"gconf-editor | desktop | gnome | peripherals | keyboard | bell_mode := on" seems to have the same effect as "xset b 50" and is presumably a more general solution.

Thanks! That's what I was looking for. Works both for startup and resume. Sample upload is still required.

Status changed to 'Confirmed' because the bug affects multiple users.

I think I'm suffering from this in 12.04. That is to say, I get no sound when I backspace an empty line in a terminal, and I have set "alert sound" to "Glass" and the Alert volume to maximum. I can hear the sound when selecting it, but I never hear it in use.

Also, FWIW, when I log in using Gnome Shell instead of Unity *then* I can hear the ("Glass") alert sound from the terminal.

Fresh 12.10 install. Error persist and commands:

pactl upload-sample actual-bell.ogg bell.ogg
xset b 100

must be run both on startup and wake. This is a papercut that cuts deeply for users that depend on the bell (like me).

I will be available for testing.

The following fixed it for me, in Ubuntu 12.04 Precise, using Gnome Classic/Compiz:

1) Add the following 2 lines to file /etc/pulse/default.pa:

load-sample-lazy bell-windowing-system /usr/share/sounds/ubuntu/stereo/bell.ogg
load-module module-x11-bell sample=bell-windowing-system

2) Run "pulseaudio -k" to restart pulseaudio.

That is, I just followed this post: https://bugzilla.redhat.com/show_bug.cgi?id=607393#c15

There is still no bell in gterm on Ubuntu 14.04. Workaround in #18 does not help.

Workaround in #10 does work in Ubuntu 14.04. After applying it, there is a bell sound in gterm.

(#18 is also good, but note that in that example "actual-bell.ogg" must be a path to a real ogg file, while "bell.ogg" seems to be a build-in identifier which must not be touched.)

Here is a trivial debdiff for pulseaudio, which uploads the bell.ogg sample.

I just want to say, what a superbly written bug report, and I hope this gets fixed.

This is still broken in 14.04. The workaround from point #4 fixes the issue for me:

pactl upload-sample /usr/share/sounds/ubuntu/stereo/bell.ogg bell.ogg

Some additional information.

In the patch to /usr/bin/start-pulseaudio-x11: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pulseaudio/wily/view/head:/debian/patches/0006-load-module-x11-bell.patch

line #9 should say "sample=x11-bell", rather than "sample=bell.ogg".

One additional change is needed to /etc/pulse/default.pa: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pulseaudio/wily/view/head:/src/daemon/default.pa.in

line #29 should be uncommented, to load an audio file as a sample named "x11-bell".

Note that line #178 in the same file would use the "x11-bell" sample name: however it should NOT be uncommented, as explained in comments right above. module-x11-bell will be loaded by X running the /usr/bin/start-pulseaudio-x11 command, via /etc/xdg/autostart/pulseaudio.desktop .

This bug is still present in Ubuntu 14.04 "pulseaudio-module-x11" version "1:4.0-0ubuntu11.1"

Worked around by running the following steps as outline here: https://askubuntu.com/questions/96511/getting-the-pc-speaker-to-beep

1. Load the module pcspkr in /etc/modprobe.d/blacklist.conf (comment it out)
2. Remove the package pulseaudio-module-x11 (that seems to absorb all XBell events)
3. Place options snd-hda-intel beep_mode=2 into /etc/modprobe.d/enable-beep.conf
4. reboot

Present in 16.04.

Is the silence of the X11 bell intentional behavior? This is a really weird case. I mean, the bug has been open for longer than half a decade and triaged for a couple of years as well. The fix also is very simple and there are proposed patches.

The attachment "debdiff for pulseaudio: upload bell.ogg" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

I've uploaded a version of Daniel Hahler's patch in comment #22 to zesty. Worked for me, I was able to hear the bell in gnome-terminal.

I believe that's the last piece of this puzzle? I'll unsubscribe the sponsors team. Please re-subscribe if there's more to do that is ready to be uploaded.

This bug was fixed in the package pulseaudio - 1:10.0-1ubuntu2

---------------
pulseaudio (1:10.0-1ubuntu2) zesty; urgency=medium

  * debian/patches/0006-load-module-x11-bell.patch:
    - Upload bell.ogg sample via pactl for module-x11-bell. Original patch
      by Daniel Hahler. (LP: #769314)
  * debian/control:
    - Add ubuntu-sounds to Suggests list, since it ships the sound used by
      default in above patch now.

 -- Michael Terry <email address hidden> Wed, 29 Mar 2017 14:24:19 -0400