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-beeeeep" 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 to once per second. It was added due to this: http://bugzilla.gnome.org/show_bug.cgi?id=322032 http://bugzilla.gnome.org/show_bug.cgi?id=170006 I do think that rate limiting is probably a good idea though once per second is a bit to much of a limitation, and I was annoyed of this myself too. Will reassign now. The metacity folks should decide if increasing the rate limit from 1/s to maybe 1/100ms would be ok. Davide, you probably should open a upstream bug about this too. Even better, provide a patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu- sounds/+bug/430203/comments/3 ------------------------------------------------------------------------ On 2009-08-28T03:52:48+00:00 Lennart wrote: OK, I have now prepped the trivial patch for upstream and opened a bz report there: http://bugzilla.gnome.org/show_bug.cgi?id=593355 Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu- sounds/+bug/430203/comments/4 ------------------------------------------------------------------------ On 2009-08-28T15:43:59+00:00 Lennart wrote: I committed this to fedora's metacity now too. But unfortunately that fails to build due to some dep problem between openssl and evolution- data-server. Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu- sounds/+bug/430203/comments/5 ------------------------------------------------------------------------ On 2009-08-29T10:37:34+00:00 Davide wrote: Lennart, thanks for taking the time for fixing this bug. Although I now recognize that the fix is very simple, I would not have known which part of the code to look at. My guess that the bug lies in libcanberra was wrong. Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu- sounds/+bug/430203/comments/6 ------------------------------------------------------------------------ On 2009-09-15T16:17:32+00:00 Davide wrote: Now that the terminal bell started working again, at least in metacity (see my comment in bug 520137), I can confirm that the fix solved the issue in rawhide. The bug is still present in F11. Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu- sounds/+bug/430203/comments/7 ------------------------------------------------------------------------ On 2009-11-16T16:26:41+00:00 Owen wrote: *** Bug 516816 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu- sounds/+bug/430203/comments/10 ------------------------------------------------------------------------ On 2009-11-16T16:27:19+00:00 Owen wrote: Not going to backport to F11 Reply at: https://bugs.launchpad.net/ubuntu/+source/ubuntu- sounds/+bug/430203/comments/11 ** Changed in: metacity (Fedora) Importance: Unknown => Medium ** Bug watch added: GNOME Bug Tracker #322032 https://bugzilla.gnome.org/show_bug.cgi?id=322032 ** Bug watch added: GNOME Bug Tracker #170006 https://bugzilla.gnome.org/show_bug.cgi?id=170006 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-sounds in Ubuntu. https://bugs.launchpad.net/bugs/430203 Title: bell.ogg is unresponsive (outside HIG response times) [regression] Status in Metacity: Fix Released Status in metacity package in Ubuntu: Fix Committed Status in ubuntu-sounds package in Ubuntu: Fix Released Status in metacity package in Fedora: Fix Released Bug description: Binary package hint: ubuntu-sounds The instantaneous beep in the default Ubuntu 9.10 preview install has been switched to a slow firing, and slow to repeat sound: /usr/share/sounds/ubuntu/stereo/bell.ogg the easiest way to cause this sound to be played in anger is to open a Terminal (eg. gnome-terminal) and hit the backspace. There is an audible delay in the latency until the sound is played and approximately 1 second until the sound is replayed (despite the key repeat likely firing at over 25 Hz. Viewing the Vorbis file with ogginfo and mhWavedit shows that it is is approximately 900 milliseconds in length! $ ogginfo /usr/share/sounds/ubuntu/stereo/bell.ogg | grep Playback Playback length: 0m:00.882s The file consists of ~50 milliseconds of silence, ~200 milliseconds of actual sound and then a further ~650 milliseconds of silence. Ideally the white space should be trimmed to the *absolute maximum*. The sound needs to play *immediately* to meet the requirements set of the HIG for interactive feedback (100 millisecond upper bound). If further delays are being introduced by the Vorbis loading then this sound (which should be immediate and responsive) should probably be converted to an uncompressed format. Failing that, the sound could be reverted to the previous short and quick 'bip' sound used previously. To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/430203/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
