Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#5691 - Fix for crash if stop pressed during voice output

Attached to Project: Rockbox
Opened by Steve Bavin (pondlife) - Friday, 21 July 2006, 22:31 GMT+2
Last edited by Linus Nielsen Feltzing (linusnielsen) - Monday, 24 July 2006, 10:15 GMT+2
Task Type Patches
Category User Interface
Status Closed
Assigned To No-one
Player Type All players
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

If the user stops playback while a filename is still being spelt, Rockbox locks up. This seems to be because playback.c waits for a Q_VOICE_STOP event (to clear voice_is_playing), but this never occurs. Looking at the changelog, it seems that this loop was added to fix crashes when pressing stop in the tree view. A slightly simpler loop, just waiting for the voice queue to be empty, will do the job and doesn't loop forever.

This patch also performs a talk_id(VOICE_PAUSE, false) to cause voice output to be truncated faster so that filenames are not spelt out over the first 10 seconds of a track. It would be neater to add a talk_shutup() function to talk.h/talk.c and use this, but I didn't want to put any dependency on the other talk.c patch I've submitted.
This task depends upon

Closed by  Miika Pekkarinen (miipekk)
Saturday, 05 August 2006, 09:30 GMT+2
Reason for closing:  Accepted
Comment by Steve Bavin (pondlife) - Friday, 21 July 2006, 22:31 GMT+2
And here's the patch!
   fixvoicestopcrash.patch (0.8 KiB) 
 apps/playback.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Comment by Steve Bavin (pondlife) - Monday, 24 July 2006, 10:37 GMT+2
It would be good if anyone knows whether Q_VOICE_STOP should be occuring in this case. If so,, a better fix would be to find out why it's not being generated (or handled).
Comment by Steve Bavin (pondlife) - Monday, 31 July 2006, 19:40 GMT+2
I've determined that there's no Q_VOICE_STOP being produced in this situation (still not sure if this is intentional).

Looking at the logic in playback.c, the loop:
while (voice_is_playing || !queue_empty(&voice_codec_queue)) ...
is resulting in an endless loop, as the queue remains empty and nothing is going to post a Q_VOICE_STOP in there.

Maybe this should read
while (voice_is_playing && !queue_empty(&voice_codec_queue)) ...
i.e. if we know the queue is empty, don't hang around waiting for a Q_VOICE_STOP?

This one-line mod is included in the updated patch attached here.

   fixvoicestopcrash.patch (0.5 KiB) 
 apps/playback.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Loading...