This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#4785 - Beginning of Wavpack files skipped when skipping to them.
Attached to Project:
Rockbox
Opened by gl (gl.tter) - Monday, 06 March 2006, 02:11 GMT+2
Last edited by Christi Scarborough (christi-s) - Sunday, 19 March 2006, 13:32 GMT+2
Opened by gl (gl.tter) - Monday, 06 March 2006, 02:11 GMT+2
Last edited by Christi Scarborough (christi-s) - Sunday, 19 March 2006, 13:32 GMT+2
|
DetailsWhen 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, 16:05 GMT+2
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.
Saturday, 20 May 2006, 16:05 GMT+2
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.
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?
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.
So is this bug fixed now or does it still exist?