Rockbox

Tasklist

FS#5082 - voice UI: clips not silenced immediately

Attached to Project: Rockbox
Opened by James Teh (jteh) - Monday, 10 April 2006, 02:49 GMT
Last edited by Dave Chapman (linuxstb) - Thursday, 25 May 2006, 20:15 GMT
Task Type Bugs
Category User Interface
Status Closed
Assigned To No-one
Operating System Iriver H300 series
Severity Medium
Priority Normal
Reported Version
Due in Version Version 3.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This bug is already well known, but I am posting it here for the purposes of completeness and tracking. :)

On the Iriver H300 (and I suspect other SWCODEC platforms), while audio playback is stopped, voice clips are not silenced immediately when they should be. For example, when moving through menus, the previous voice clip should be silenced and the new one played as soon as the next movement is made. At present, the previous clip continues playing, so one must wait for the voice UI to 'catch up' when moving through menus, which makes for rather slow navigation. Eventually, many seconds/clips after silencing should occur, the previous clips do get silenced and the current clip played.

While audio is playing, the next clip does get played immediately, although the previous clip does not get silenced properly. This isn't such a problem, though, as navigation is still quite acceptable, especially given that audio is playing at the same time.
This task depends upon

Closed by  Steve Bavin (pondlife)
Tuesday, 24 October 2006, 09:24 GMT
Reason for closing:  Fixed
Additional comments about closing:  I\'ll take the lack of comment as a yes then!
Comment by James Teh (jteh) - Friday, 28 April 2006, 10:30 GMT
Update: Since the rework of the voice UI, the next clip does not get played immediately without silencing the previous clip during playback, but silencing of previous clips is still markedly faster than while playback is stopped. The sluggishness in silencing clips while playback is stopped (up to 4 seconds at times) remains unchanged. However, on the SoftwareCodecPlayback wiki page, BrandonLow notes:
• Voice responds faster when audio is playing than not. This is solveable by forcing pcm playback earlier when decoding voice only, in the voice insert split callback.
Comment by Steve Bavin (pondlife) - Wednesday, 27 September 2006, 08:05 GMT
 FS#6072  implements a quick flush of the PCM data when decoding voice only. Please test and report on that patch.
Comment by Steve Bavin (pondlife) - Thursday, 28 September 2006, 16:52 GMT
Should be much improved while playback is stopped now. Let me know if you think this can be closed.

Loading...