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
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
Hope you can help me with this. As I said, that patch really makes the
voice much more responsive.
Received on 2006-10-24