On Wed, 27 Sep 2006, Steve Bavin wrote:

> Hi Jacob,
>
> The problem is that the unwanted voice output has already been put in the
> PCM buffer (the final output stage). I've made another patch which might
> help by clearing that buffer to remove any previous voice when starting a
> new voice clip. (Unfortunately, I can only do that whilst music is not
> being played, because there's no way to separate out the voice and music.)
>
> The patch is at http://www.rockbox.org/tracker/task/6072

Hi,

Thanks a lot for that patch, it does help a lot. But I think there's a
little glitch with it however.

I was trying to add some more verbosity in say_bookmark(), and I happened
to use talk_file() in there. I noticed some of my queued voice clips were
being interrupted and some later clips began playing ahead of time. I
think what's happening is that my code is being delayed by some file
operations (I'm opening a file, and talk_file() too), and there is enough
time for the voice clip queue to be copied entirely to the pcm buffer.
At that point when I mean to enqueue more voice clips, your patch zaps the
pcm buffer that was still playing.

For example I would have it say:
     bookmark 1 directory `talk_file(<my_audio_book>)` index blabla.

I first enqueue "bookmark 1", then I have to check that the thumbnail file
exists, and talk_file has to read it. It takes a fraction of a second,
imperceptible really, but by that time "bookmark 1" has moved to the pcm
buf but hasn't been spoken yet. It gets zapped. I hear only:
     directory <my_audio_book> index blabla.

Your patch assumes that if (!voice_is_playing) then it's a new utterance
that is meant to interrupt, and not be enqueued.

I'm new to the code, and playback.c isn't the most fun place to hack... so
I thought I'd ask. First am I making sense? Assuming I am, seems to me we
need an indication of whether shutup() was called. I'm just not too sure
where that flag should go. Could it somehow be given as a parameter to
Q_VOICE_STOP perhaps?

Hope you can help me with this. As I said, that patch really makes the
voice much more responsive.

Thanks

-- 
Stéphane Doyon
<s.doyon_at_videotron.ca>
http://pages.infinit.net/sdoyon/