From: Björn Stenberg <bjorn_at_haxx.se>
Date: Wed, 27 Oct 2004 10:28:32 +0200

Spam Me wrote:
> 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).

Loading from disk does not need a separate process. It's better if the decoder simply fills up its' own input buffer when it runs out. The only reason to use two processes would be if we are short on cpu time, which we do not expect to be.

Also, rendering transitions after decoding/buffering would be very expensive, since it involves moving large amounts of data around in memory. It is better to make the renderings immediately in the output buffer, as the data comes in from the decoder. That way no data has to be moved.

> - 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?

Yes, we have a working single-buffer system today. We just need to add a second buffer.

> 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?

Actually the decode process is not real-time critical at all. As long as it gets enough cpu time in total to decode data faster than it is played, it doesn't matter when it executes.

A few words on Rockbox design: KISS (Keep It Simple, Stupid) is a very highly regarded design principle in Rockbox. We don't make solutions any more complex than they have to be to get the job done. We actively resist "designing for the future" or making elegant abstractions. Instead we design and write code to do exactly what we want right now. Nothing more. While this might sound like it would result in bad design and sloppy code, in reality it results in simple designs and readable code that is easily modified and expanded as the needs arise.

-- 
Björn
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox

Received on 2004-10-27