This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#8067 - Sound effect instead of speech for "Loading..." splash
Attached to Project:
Rockbox
Opened by Stephane Doyon (sdoyon) - Friday, 02 November 2007, 04:48 GMT+1
Opened by Stephane Doyon (sdoyon) - Friday, 02 November 2007, 04:48 GMT+1
|
DetailsSome feel that speaking "Loading" when anew track is selected is
annoying, particularly if music is already playing. I don't find it particularly annoying myself, but it is inelegant. It would however be appropriate to give confirmation of the key press and an indication that a possibly longish delay should be expected. Here's a suggestion for an alternative. Instead of a voice clip that speaks "Loading", how about a small unobtrusive sound clip? It's more discreet, feels smoother. I used to use a nice tiny chirping sound called twip.wav. Not sure where I got that, google finds a reference that indicates it may be from OS/2. I found another clip, almost as nice, that should be freely redistributable. /usr/share/sounds/gtk-events/activate.wav on my machine, belongs to the gnome-audio RPM, which is (supposedly) LGPL. Uploaded as LANG_WAIT.wav. Put LANG_WAIT.wav under tools/, and apply the patch. The patch also moves and adds a couple of LANG_WAIT splashes. I haven't tested all the cases. The idea is that the splash makes sense only if it is executed before a disk spin up is triggered. audio_play() calls talk_force_shutup(), so that this splash is often not heard at all, especially on flash-based players. This works out well when operations preceding audio_play() need to spin up the disk. It does however needlessly suppress the splash when the only delay comes from buffering the track to play. The LANG_WAIT splash itself does a shutup, so it would be possible to remove the shutup from audio_play() (assuming all callers use this splash, which they pretty much do). However it doesn't seem to work out so nicely. audio_play() causes the pcm buffer data to be scrapped in many cases. Also in some cases I've heard the splash half a second AFTER the new track has started, presumably due to the voice thread being delayed, possibly because of the codec swapping... Playing the wait clip after the fact sounds quite horrible, so I'll leave the shutup in place in audio_play() until a way can be found to force the wait clip to play while buffering is taking place. Please let me know whether this solution takes the annoyance out of the wait splash and whether it sounds good or not. |
This task depends upon
2) I'm sure we could find a better sounding effect ;)