|
Rockbox mail archiveSubject: Re: Gapless Playback EngineRe: Gapless Playback Engine
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 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |