early load of module-x11-bell leaves standard X bell active too

[liblit]

Overview

The standard X bell is not suppressed after I load module-x11-bell during login. It is correctly suppressed if I subsequently unload and reload that module, though.

Details

I run the following script on login to load up module-x11-bell:

#!/bin/sh -e

pactl upload-sample "$HOME/lib/bell.wav" x11-bell
pactl load-module module-x11-bell "display=$DISPLAY" sample=x11-bell >/dev/null
xset b 100

The script is actually launched as part of the GNOME autostart system, i.e., via a .desktop file in ~/.config/autostart.

Once the session is up and going, X bell calls play the expected PulseAudio sample. However, they also produce the standard X bell at the same time. That is unexpected and inconsistent with the module-x11-bell documentation.

If I subsequently unload module-x11-bell, then we're back to the standard X bell and no PulseAudio sample. If I then reload module-x11-bell, the standard X bell is suppressed and I hear only the PulseAudio sample. That is the expected, documented behaviour, and is how things should have behaved the first time the module was loaded.

[lennart]

Is it possible that som eother program is also catching the X11 bell events? (note that gnome metacity does that)

We don't load this module by default since most DEs do catch the event anyway.

[liblit]

I think it unlikely that some other program is also catching the X11 bell events. I am running compiz-fusion, not metacity, and I do not believe I have any special effects wired up to the bell. More importantly, observe that the standard bell is no longer played after I unload and reload module-x11-bell later in the session. Presumably if some other program were catching the X11 bell events, it would continue to do so even after that module reload?

Is there some sort of race condition here? Perhaps module-x11-bell racing with some other bell-event-catching program, or even racing with the X server itself? Is there some way for me to query who's catching the bell at any given moment? That would let me answer your original question more authoritatively.

[liblit]

On closer inspection, I find that compiz's "audible bell" option was enabled. Disabling this resolves the problem as originally reported.

I still don't understand why the problem only appears initially, and disappears when module-x11-bell is unloaded and reloaded. That still smells like some sort of race condition to me. But if you think the compiz interaction is too obscure to be worth investigating further, I don't mind considering this bug closed.

Thanks!

[lennart]

Yes this is a race condition. There is no proper access scheme for the bell events. I think the logic is that the last program asking for it gets the bell events. So if you load PA before compiz then compiz will get those events. If you then reload the m-x-b then it will get those events. But tbh i don't really think this needs to be fixed. The current scheme is good enough.

Again, the right place to handle this event is probably the WM, not PA. (that's because the WM needs to implement visual bell) That's why we don't load the module by default in PA.

Also see:

http://bugzilla.gnome.org/show_bug.cgi?id=557921

[liblit]

I'm convinced. Thanks for the lucid explanation.