Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category User Interface
  • Assigned To No-one
  • Operating System Iriver H300 series
  • Severity Medium
  • Priority Very Low
  • Reported Version
  • Due in Version Version 3.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by jteh - 2006-04-10
Last edited by linuxstb - 2006-05-25

FS#5082 - voice UI: clips not silenced immediately

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.

Closed by  pondlife
2006-10-24 09:24
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

I\'ll take the lack of comment as a yes then!

jteh commented on 2006-04-28 10:30

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.

pondlife commented on 2006-09-27 08:05

 FS#6072  implements a quick flush of the PCM data when decoding voice only. Please test and report on that patch.

pondlife commented on 2006-09-28 16:52

Should be much improved while playback is stopped now. Let me know if you think this can be closed.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing