Launchpad has imported 10 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=498608.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2009-05-01T13:20:42+00:00 Davide wrote:
Description of problem:
If multiple alert-triggering events occur too close in time, the alert
sound is only played upon the first event, whereas no alert sound is
played for the remaining alert-triggering events.
Consider the case of two successive alert-triggering events. If the
delay between the two alert events is longer than the duration of the
alert sound, two distinct alert sounds are played. If, however, the
second alert event is triggered before the sound for the first alert
event has finished playing, no alert sound for the second alert event is
played. If more than two event-triggering events occur within a time
window shorter than the duration of the alert sound, only one alert
sound is played. This is bad because all alerts but the first one
essentially vanish.
In a situation where an alert is triggered every time a given key is
pressed, pressing the key twice must lead to two alert sounds, no matter
how quickly the two keypresses are done. This way, the user receives
feedback on each of the two keypresses. Issuing a single alert sound
would leave the user without feedback about the second keypress.
In order to combine the two alert sounds, two solutions come to my mind:
1. the first alert sound is interrupted and the second alert sound is played
immediately afterwards
2. the second alert sound is superimposed to the first one
Note that when the system beep was used for alerts (prior to the introduction
of libcanberra (*), I think), solution 1 was in place. The first beep would be
interrupted to give way to the second beep. The user would (sloppily speaking)
hear "Bee-bep" and hence receive the information that two separate beeps
had been issued.
(*) Thanks to bug 498594, this situation can currently be observed by
turning the desktop effects on.
Version-Release number of selected component (if applicable):
As in the 2009-04-30 rawhide. In particular:
libcanberra-0.12-1.fc11.x86_64
pulseaudio-0.9.15-11.fc11.x86_64
alsa-lib-1.0.19-3.fc11.x86_64
How reproducible:
always
Steps to Reproduce:
1. Ensure desktop effects are disabled (see bug 498594) and that the sound
theme is set to
"Default"
2. Open a gnome-terminal window
3. Push the "down" arrow very quickly two times within the gnome-terminal
window to trigger two consecutive alert events
4. Keep the "down" arrow pressed to trigger a large number of consecutive alert
events
Actual results:
In step 3, a single alert sound is heard.
In step 4, the alert sound is played periodically, with the period equal to the
duration of the alert sound.
Expected results:
In step 3, two alert sounds be heard (either with the first one being
interrupted to give way to the second one, as in solution 1, or with the second
one superimposing on the first one, as in solution 2).
In step 4, multiple alert sounds be heard (again, either according to solution
1 or to solution 2), with the speed at which new alert sounds are started being
equal to the keypress repeat speed specified in the keyboard preferences.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu-
sounds/+bug/430203/comments/0
On 2009-06-06T08:50:40+00:00 Davide wrote:
I found more information to support my request. The GNOME Human Interface
Guidelines contain the following:
(Source:
http://library.gnome.org/devel/hig-book/stable/feedback-response-times.html.en)
"Verify that your application provides feedback within 100 milliseconds
(0.1 second) after each key press, movement of the mouse, or other
physical input from the user."
In the scenario described in the bug report, this clearly does not
happen.
I hope that libcanberra is the correct component to report the bug
against.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu-
sounds/+bug/430203/comments/1
On 2009-06-09T14:56:44+00:00 Bug wrote:
This bug appears to have been reported against 'rawhide' during the Fedora 11
development cycle.
Changing version to '11'.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu-
sounds/+bug/430203/comments/2
On 2009-08-28T03:35:06+00:00 Lennart wrote:
This is actually a "feature" in metacity:
http://git.gnome.org/cgit/metacity/tree/src/core/display.c#n2387
It limits bell events
