Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Version 3.1
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by sdoyon - 2007-11-01
Last edited by MikeS - 2011-06-30

FS#8066 - End of voice clips are cut off when playback stopped

Some .talk clips are not played until the end. It’s pretty noticeable: I
have “boo” instead of “books”, “musi” instead of “music”, and on .ogg
files the end sounds like “dot aw” instead of “dot o g g”… I have one
directory named “baba” (for tests obviously). I hear just “ba”. some are
fine though. Names that do get clipped get clipped every time, and always
at the same point, at least so long as I don’t change to a different svn
rev.

This happens consistently on my X5, and never on my e200.
It does not happen while music is playing.

The commit that introduced this problem is:
r15006 | jethead71 | 2007-10-06
Something about PCM interface unification.

A hint: reverting this part of the commit:

        /* There may be more data waiting to flush, try to use it */
        if (pcmbuf_flush_fillpos())
            goto process_new_buffer;

makes the symptom go away. jhMikeS warns this is unsafe (and I do believe
it may cause strange UI unresponsiveness), but anyway it’s a hint.

Another observation: talk.c enqueues a short (0.3s) clip of silence at
the end of an utterance. Contrary to what I said on IRC, the silence clip
is added only when the final clip is from the voice file, and not after a
.talk clip. If I disable the addition of silence, then every voice
utterance is cut off before the end, including menu entries. OTOH if I
remove the “&& p_lastclip != p_thumbnail” condition to enable adding
silence for .talk clips also, then my file names are spoken
properly.

Closed by  MikeS
2011-06-30 07:23
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Voice operates differently since r30097

This is my suggested workaround.

But it would be best to just fix the actual pcm bug instead.

MikeS commented on 2007-12-05 17:11

I can say with high certainty it’s not the decoding portion so yes, of course getting to the bottom of the PCM bug is best. Got any clips that get cut off to post? Anyone that does post any, mention the target they’re used on though I can’t imagine it should be too picky.

Since cutoff occurs just because the silence clip is removed with normal voice, I may be able to just work with that.

The unsafeness is twofold: 1) Starting PCM in insterrupt context is not safe without using pcm_play_lock/unlock in all non-interrupt code. metronome had problems because of that. 2) the pcmbuf_flush_fillpos call will create recursive calls to the callback.

Here is a .talk clip that gets cut off when music isn’t playing. I am using a first generation 2 GB iPod Nano.

Here is another talkclip which is cutoff. I tested it with my h120.
It is also cutoff on the sim, so it should be possible to debug this.

I also noted that it is only cutoff if there is nothing else played. (eg. while playing music, its spoken fine.)
To add the small silence from the menus also to the talkclips works fine, but it would be better to find the real bug in the pcm playback.

This also happens with all speech (e.g. menus) for me.

I’m not so sure this is (just) a PCM issue. I’ve been experimenting on the sim. If you remove the pcmbuf_play_stop() call from voice_thread.c (apply the attached patch), then you’ll find that the cutting off no longer happens, but the last part of each clip isn’t played until the next voice clip is triggered.

For example, on the main menu:
- With SVN code, I get the Playlists entry spken as “Playlist”.
- With the patch applied I get the full “Playlists”. I select FM Radio, it speaks “FM Radi”; if I then move down to Playlists, it speaks “o Playlists”.

I wonder if something is being held back in the Speex decoder?

I should clarify that the above patch is not a fix for this issue, nor is it intended to be - just a way for me to try and uncover further layers of the onion we call voice support.

Several years later I no longer seem to have this problem. Stephane, if you’re still around, could you recheck with a current build?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing