dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: feedback on voice UI changes

Re: feedback on voice UI changes

From: Brandon Low <>
Date: Sun, 23 Apr 2006 00:28:21 -0500

Jamie, thanks for the feedback! Comments below. At this point, voice
bugs are welcome on flyspray or my wiki page so we can track them.


On Sun, 04/23/06 at 14:57:04 +1000, James Teh wrote:
> Hi all, particularly Brandon,
> Thanks for the much needed and very nice work on the voice UI. A few
> notes and questions:
> * Not sure whether this was intentional, but the 'voice UI crash while
> connected to charger bug' appears to be fixed!

I totally reimplemented the thread interaction for voice, so bugs like
this were expected to go bye bye :)

> * The dropping of audio playback to a lower volume (a.k.a. ducking)
> appears to be removed for the present. I assume this will return when
> you get a chance to implement it again?

Really? Wasn't aware of changing this, I'll see what I might have done
to mess it up.

> * The voice UI no longer appears to read a whole stack of unrelated
> clips for no apparent reason. Sometimes, it used to start reading
> numbers, letters and other clips when in various settings screens, but
> this doesn't appear to be happening now. Nice!
> * I know you mentioned there was little chance of voice while playback
> is paused in a previous message, but another work around was suggested.
> Is this work around likely, even if it is conditional on whether a voice
> file is loaded, or is this not something you are willing to consider at
> this point?

I don't recall the work around, can you refresh my memory?

> * Currently, voice clips still don't shut up when they should; e.g.
> moving to another menu item while the current voice clip is playing
> doesn't silence the current clip. I estimate that the delay before the
> first clip is silenced correctly is just under 4 seconds. Is this likely
> to be fixed or not in the near future?

Hmm, I don't have any voice clips that long -- currently it really
depends on how much of the 'old' clip has been decoded and written into
the pcm buffer prior to the new clip being selected. If the whole 'old'
clip is already buffered, I don't have a way to 'un mix' it at this
> Thanks once again for the great work.

I'm glad this seems like an improvement :)
> Jamie
> --
> James Teh
> Email:
> WWW:
> MSN Messenger:
> Jabber:
> Yahoo: jcs_teh
Received on 2006-04-23

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy