From: Jacob Rau <jacob.rau_at_gmail.com>
Date: Sat, 23 Sep 2006 22:51:00 -0400

Steve Bavin wrote:
>> It just doesn't seem like that daunting of a task to add a "dump queue"
>> type function to blow away the queue's contents once the user has
>> scrolled away from the directory/file. It might be somewhat of a hack,
>> but it would seem there is no excuse to not immediately kill decoding
>> and playing of the previous voice clip. Once I get cygwin installed OK I
>> will see what havoc I can cause in the voice code...hehe...
>>
>
> Actaully, the voice queue is dumped in this fashion (and I've put some
> debugging in here to prove that it is dumping correctly).
>
> I think the problem is that the MP3 voice data has already been sent to the
> decoder or PCM buffer, and there's currently no way to reverse that.
>
> I don't have an iPod, but would be interested to know if the above patch
> improves voiced scrolling much...
>
> Steve Bavin
>
>
>
>
>
I got CYGwin running and functioning. I'm running a copy of RB, patched
with the patch you mentioned. I ran talkbox (I plan to rewrite it
because the existing interface sucks and I know vb6 pretty well) and the
voice clips are what I was using to test with. What difference am I
supposed to notice? It seems just as lag-filled as usual. I really don't
think that the lag is anything to do with the processor speed...the code
is so d_at_m confusing that I am having problems figuring it out. Do we
need to simplify--make the clips into WAV audio? I'm not exactly sure
how the rockbox output code is built.

I can't find a good page of specs, but why not use extra cpu time to
decode voice clips and store them in ram, in pcm format? That way they
could easily be played later.

I don't know enough about RB's internals to know if any of what I said
is valid, so let me know if any of it is worth anything.

I have learned to go slowly; wait for the voice to catch up, move again,
wait,...

I dunno.
Jacob
Received on 2006-09-24