Rockbox mail archiveSubject: Wavpack Hybrid on the Sim!
Wavpack Hybrid on the Sim!
From: Bryan Jacobs <no_at_landwarsin.asia>
Date: Sat, 27 Jun 2009 20:24:17 -0400
This week's Wavpack Hybrid objective was accomplished; hybrid files can
now be played back on the sim (and, theoretically, on real targets)
The patch is at:
Here's how this works:
A new buffering API call has been added that opens a "secondary" file.
When this file is opened, the "end" of the buffer is moved down to the
current write position (or at most 3/4 of the total buffer size if the
current end is before that). This clears some space for the secondary
file to occupy while leaving any other files where they are. (TO DO:
make sure not to step on resident files' toes)
Now there are essentially two distinct buffers, one occupied by
anything using the "primary" file functions, and one occupied by
anything using the "secondary" file functions. The relative sizes of
these two buffers can be adjusted at will.
metadata/wavpack.c, upon determining that the current file has
FLAG_HYBRID set, loads the correction file (determined by appending a
'c' to the trackname) and if that goes successfully, stores a buffer
handle into a new field in the mp3entry struct. The Wavpack codec
finds this field and uses it to start lossless decoding.
On my plate for this coming week:
- Currently only one secondary file can be buffered; solve this by
removing the "secondary" buffer's assumptions
- If the buffer is in the wrong state when the open_secondary_file call
is made the resident information will get clobbered. I need to stop
this from happening.
- Seeking is still not implemented
- There is sure to be constructive criticism about this methodology. I
need to take it into account.
- When the last "original" file winds down to zero, the "secondary"
buffer should expand to fill the whole buffer
- When a new "primary" file enters the buffer (on track change), the
"secondary" buffer needs to give way
At least for the first part of the week, I'm going to focus on nailing
down all the corner cases of interactions between normally buffered
stuff and things using this new API. But I'm pretty happy that real
lossless decoding is working now :-).