• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Codecs
  • Assigned To No-one
  • Operating System Iriver H100 series
  • Severity Low
  • Priority High
  • Reported Version
  • Due in Version Version 3.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by gl.tter - 2006-03-06
Last edited by christi-s - 2006-03-19

FS#4785 - Beginning of Wavpack files skipped when skipping to them.

When Wavpack files end and continue onto the next file naturally, everything works, but when skipping to the next/prev file in the middle of playback, the first ~500ms are not played.

Closed by  linuxstb
2006-05-20 14:05
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

The original bug reporter says this is now fixed (which I suspect was a happy side-effect of the playback engine reworking) and no-one else has reported the issue.

Re. the ~500ms or so missing from track starts when skipping in Wavpack,
I’ve narrowed it down to audio_load_track(), line 1195 - a file offset of 1
is applied when skipping, and this causes wavpack.c to skip the initial
audio data (if a file is selected manually from the file browser, the offset
is zero and thus plays fine).

The problem call comes from audio_thread(), line 1817:

if ( == SYS_TIMEOUT && play_pending)
{ = Q_AUDIO_PLAY; = (bool *)1;

The offset ( is set to 1 here - anybody know what’s going on?

Both references are in playback.c.

There’s another similarly strange call in initiate_dir_change(), line 1791:

  queue_post(&audio_queue, Q_AUDIO_PLAY, (bool *)true);

And sure enough, if you skip a directory, the start of the first track is missing again.

Why are these setting boolean values (especially as true compiles to 1 and not -1, which the code would at least treat differently)?? Are these remnants from an old version of the code or am I missing something?

Setting both values to zero corrects the problems and is showing no ill effects thus far.

mmohr commented on 2006-04-27 14:53

I don’t see any of the mentioned code parts anymore.
So is this bug fixed now or does it still exist?

This report was already resolved previously? - the bug is fixed.


Available keyboard shortcuts


Task Details

Task Editing