From: Brandon Low <lostlogic_at_lostlogicx.com>
Date: Sun, 23 Apr 2006 07:18:14 -0500

On Sun, 04/23/06 at 17:52:30 +1000, James Teh wrote:
> On Sun, Apr 23, 2006 at 12:28:21AM -0500, Brandon Low wrote:
> > > * 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?
> Something about only pausing on PCM buffer boundaries ... I can hunt
> through the messages in the archives and post again if it'll help.

Ah, yes, this is an option, but again, not something I expect to be able
to do before 3.0.
>
> > > * 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
> > time.
> Does this mean the decoder is decoding about 4 seconds ahead of
> realtime? Let me try to give some examples of when this occurs:
> * Scroll through a menu fast. Notice that although you might have
> skipped items 2, 3 and 4, the voice UI still plays those clips; they
> aren't silenced.
> * With file name spelling enabled, move through the file browser. This
> is when the issue is a huge problem; you have to wait for the voice UI
> to spell several file names before it catches up.
> * Go to the Info->Rockbox Info menu item, then exit. The voice UI will
> take about 4 seconds to 'catch up'.

The decoder is indeed ahead of realtime, when audio is stopped, this can
be solved in a fairly trivial way, when audio is playing, I'm not sure
how much will be doable before 3.0, but I believe Jens also has some
thoughts on it.
>
> Thanks again.
>
> Jamie
>
>
> --
> James Teh
> Email: jamie_at_jantrid.net
> WWW: http://www.jantrid.net/jamie/
> MSN Messenger: jamie_at_jantrid.net
> Jabber: jteh_at_jabber.org
> Yahoo: jcs_teh
Received on 2006-04-23