Rockbox

Tasklist

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

Attached to Project: Rockbox
Opened by Stephane Doyon (sdoyon) - Thursday, 01 November 2007, 21:06 GMT
Last edited by Michael Sevakis (MikeS) - Thursday, 30 June 2011, 07:23 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Version 3.1
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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.
This task depends upon

Closed by  Michael Sevakis (MikeS)
Thursday, 30 June 2011, 07:23 GMT
Reason for closing:  Fixed
Additional comments about closing:  Voice operates differently since r30097
Comment by Stephane Doyon (sdoyon) - Wednesday, 05 December 2007, 14:11 GMT
This is my suggested workaround.

But it would be best to just fix the actual pcm bug instead.
Comment by Michael Sevakis (MikeS) - Wednesday, 05 December 2007, 17:11 GMT
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.
Comment by Anna Dresner (woodyanna) - Thursday, 06 December 2007, 20:34 GMT
Here is a .talk clip that gets cut off when music isn't playing. I am using a first generation 2 GB iPod Nano.
Comment by Dominik Wenger (Domonoky) - Sunday, 20 April 2008, 13:00 GMT
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.

Comment by Steve Bavin (pondlife) - Tuesday, 19 August 2008, 08:05 GMT
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?
Comment by Steve Bavin (pondlife) - Tuesday, 19 August 2008, 08:10 GMT
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.
Comment by Steve Bavin (pondlife) - Tuesday, 17 May 2011, 11:48 GMT
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...