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
<[EMAIL PROTECTED]>
http://pages.infinit.net/sdoyon/
