GNOME Bugzilla – Bug 607906
Metacity should not handle sounds for system bell events
Last modified: 2020-03-17 14:40:31 UTC
Sometime between 2.25.144 and 2.28.0, Metacity started using libcanberra to produce a nice sound for system bell events, in lieu of the usual PC speaker square-wave beep. While I appreciate the thought behind it, this behavior is problematic because it (1) is (apparently) impossible to disable, (2) produces identical rate-limiting of visual and audible bells, (3) causes behavior different from Compiz, and (4) can be better handled by another software element. 1) While many users undoubtedly prefer the libcanberra bell, some of us prefer the PC speaker beep for technical (no speakers on line-out) or sentimental reasons. In an epic bug hunt on Launchpad [1], several of us attempted to switch back to the PC speaker beep. The only way we were able to do this was to patch and recompile Metacity! This is hardly user-friendly. (Heck, just figuring out that it was Metacity that was capturing the system bell events was an adventure in and of itself.) 2) Metacity includes code to rate-limit its handling of system bell events. I presume this was put in place to keep visual bells from flashing the screen too often. Now that Metacity is also handling audible bells, the audible bells are also rate limited. This has been reported in several places [2,3], and was "solved" in Metacity by changing the rate-limiting frequency from 1 Hz to 10 Hz [4]. However, this seems too fast for the visual bell (has anyone considered what this might do to an epileptic?) while still being a bit sluggish for the audible bell (10 ms is generally close enough to instantaneous for sound). The visual and audible bells should not share the same rate-limiting. 3) Compiz does not (yet) use libcanberra to handle the system bell. This means that when a user switches between Metacity and Compiz (probably by using a dialog entitled "_Visual_ Effects"), they confusingly get a change in _audible_ effects [5,6]. 4) While each of these issues could be solved while keeping Metacity's ability to play sounds for system bell events, this capability is unnecessary. Pulse Audio has a module, module-x11-bell, which is specifically designed to play sounds for system bell events. Configuring or disabling this module would be easy for the user. Moreover, it is window-manager-agnostic, so the same behavior can be achieved in Metacity, Compiz, and others, without any duplication of code. In short, Metacity can avoid these problems by being "boring" and letting another program handle audible system bell events. [1] https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/486154 -- Note that several separate bugs are under discussion here. [2] https://bugs.launchpad.net/ubuntu/+source/ubuntu-sounds/+bug/430203 [3] https://bugzilla.redhat.com/show_bug.cgi?id=498608 [4] https://bugzilla.gnome.org/show_bug.cgi?id=593355 [5] https://bugzilla.redhat.com/show_bug.cgi?id=498594 [6] http://defect.opensolaris.org/bz/show_bug.cgi?id=11946
Created attachment 152126 [details] [review] Disable Metacity's handling of audible bells Here is the patch that we used in [1] to disable Metacity's capture of audible system bell events. I am not at all familar with the Metacity code base, so I produced this by reverting sections of the code to that from 2.25.114 (the version from Ubuntu 9.04, which I knew to work). I've been running with this patch for the past several weeks with no apparent problems.
Any comments at all on this issue? Downstream is telling me they need to wait for metacity to make these changes. If you won't be doing so, I'd like to know so I can go back and present this to downstream as an integration issue.
Review of attachment 152126 [details] [review]: I'm not a metacity developer, but this patch looks good to me.
This problem exists, and it is a problem for a good number of users. The downstream patch has 76 comments and 25 people have marked themselves as being affected. The patch works for me, but requiring users affected by a problem to hunt for a patch and recompile is hardly the right way, IMHO. I'd be really glad if it was taken up.
So, instead of you having to recompile metacity to disable sound events, you propose a patch that forces the rest of the world to recompile metacity to get them back ?!
maybe we could just patch metacity to have it be configurable? and you can leave the default behavior be metacity handling sound events, but in case someone is using pa with metacity, it can be disabled, as is the case with most ubuntu users using metacity (as I understand it, anyway) wouldn't that make everyone happy? what I don't understand is the general disagreement of if a 'sound system' ala PA should be handling sound events, or if the window manager should be handling them, or X itself, or what. sound in linux has been a crapshoot for years. we're not exactly presenting a coherent sound system here. seems the window manager folks need to sit down with the sound system folks and hash out the intended behavior across the board (don't laugh!) or is that the purview of the free desktop folks? if this gets marked as wontfix or whatnot, Im sure the ubuntu metacity maintainers can just patch ubuntu's version of metacity, but that seems absurd. no point in going against intended behavior for a single distribution. is this not an issue using metacity + pulseaudio + gnome in redhat? or arch?