Rockbox

Tasklist

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

Attached to Project: Rockbox
Opened by gl (gl.tter) - Monday, 06 March 2006, 01:11 GMT
Last edited by Christi Scarborough (christi-s) - Sunday, 19 March 2006, 12:32 GMT
Task Type Bugs
Category Codecs
Status Closed
Assigned To No-one
Operating System Iriver H100 series
Severity Low
Priority Immediate
Reported Version
Due in Version Version 3.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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

Closed by  Dave Chapman (linuxstb)
Saturday, 20 May 2006, 14:05 GMT
Reason for closing:  Fixed
Additional comments about closing:  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.
Comment by gl (gl.tter) - Friday, 31 March 2006, 13:56 GMT
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 (ev.id == SYS_TIMEOUT && play_pending)
{
ev.id = Q_AUDIO_PLAY;
ev.data = (bool *)1;
}

The offset (ev.data) is set to 1 here - anybody know what's going on?
Comment by gl (gl.tter) - Friday, 31 March 2006, 13:57 GMT
Both references are in playback.c.
Comment by gl (gl.tter) - Monday, 03 April 2006, 17:09 GMT
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.
Comment by Matthias Mohr (aka Massa) (mmohr) - Thursday, 27 April 2006, 14:53 GMT
I don't see any of the mentioned code parts anymore.
So is this bug fixed now or does it still exist?
Comment by gl (gl.tter) - Friday, 19 May 2006, 22:04 GMT
This report was already resolved previously? - the bug is fixed.

Loading...