From: Spam Me <spammailtrap_at_gmail.com>
Date: Tue, 26 Oct 2004 22:47:49 +0200

Nice input, Björn. I have some initial thoughts of a possible design.
I have only done initial research on the different codecs and the
archos rockbox playback engine, so please comment if you have
different views or ideas.

Because the iRiver hardware has 32MB (minus memory used for
TagDatabase and firmware program etc.) the memory can contain several
songs (normally ~3 songs).

Here is a simple illustrative ASCII drawing of the raw mp3 in memory
(before decoding).

|~~~~~~~~~|~~SONG1~~|~~~~~~000#~~~~~~~~~|~~SONG2~~|~~~000000#~~~~~~~~|~~SONG3~~|~~~~~~~~0|

|....| = defining a mp3 frame
~ = audio samples (can be decoded to PCM)
# = new song transition
0 = zero-padding within a fixed-size mp3 frame

The engine could for example consist of at least 3 processes (tasks). A
- "load from harddisk" process
- "decode/play" process (may be split into 2 processes)
- "transition render" process (gapless/crossfade).

The main idea is to let the "transition render" process prepare the
parts where the playback engine needs to change codec-decoder,
samplerate (kHz), strip zero-padded samples (mp3 only), declick sample
offsets (can happen if not ripped correctly), crossfading of tracks
(variable number of sec.) etc.

The rendered transitions consists of audio samples from the decoded
start/end frames (variable number) and are stored in buffers as PCM.
These prepared PCM buffers can be fed directly to the UDA1380TT.

PROCESS 1: Load-process
Loads raw mp3/Ogg/FLAC/MPC tracks into memory

- While still decoding i.e. song 3, new songs have to be loaded from
the harddisk into memory. Memory which contains non-played/decoded
tracks can not be utilized. A simple "ring buffer" implementation will
probably do the job. Does Rockbox already have such an implementation
or something similar?

- The playback engine needs to know how much
playback-time/buffer-memory is left, so the harddisk can be spinned up
and new track data be loaded in time before running out of
"song-buffer" data.

PROCESS 2: Decode/Play-process
Decodes the "song-buffer" data with the appropriate codec. It may
either be able to send the decoded data directly on-fly to the
UDA1380TT or maybe it is necessary to store the PCM data in memory and
let another process feed the data to the UDA1380TT. This process is of
course real-time critical. Can it be a problem that the Rockbox kernel
don't do priority-scheduling of tasks?

- It is necessary to have a management system of the which frames are
part of the "rendered transition" buffers and which frames should be
decode from the song-buffer. Should not be too complex to implement.

PROCESS 3: Transition Render-process
This process renders the transitions between songs. The processing is
done while the player is playing the tracks and thus it not extremely
real-time critical.

If it is just this simple, then it makes you wonder why iRiver spent
several months making a useless "Gap Delete" function. :) No,
seriously I think we will experience several unforeseen problems once
we get really into the research on this issue. That is why, doing a
little research now might not be a bad idea :)
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2004-10-26