dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox Developer Conference 2002

Comparison of Recorder and Player

Well, almost. :-) Björn, Linus, Daniel and Kjell sat down at Linus' house friday night (2002-04-19) with our Archoses and had a long and fruitful discussion about software design. Here are a few things that we discussed:

Application Programming Interfaces

We want to try to stick to POSIX where these exist and are practical. The reason is simply that many people already know these APIs well. Here are a few which haven't already been defined in the code:

File operations

  • open
  • close
  • read
  • write
  • seek
  • unlink
  • rename
Contest: Spot the development box!

Directory operations

  • opendir
  • closedir
  • readdir

Disk operations

  • readblock
  • writeblock
  • spindown
  • diskinfo
  • partitioninfo

We also decided that we will use the 'newlib' standard C library, replacing some functions with smaller variants as we move forward.


We spent much time discussing and debating task scheduling, or the lack thereof. First, we went with the idea that we don't really need "real" scheduling. Instead, a simple "tree-task" system would be used: A main-loop, a timer tick and a "bottom half" low-priority interrupt, each with an event queue.

Pretty soon we realized that we will want to:

  1. Use a timer tick to poll disk I/O (assuming we can't get an interrupt)
  2. Perform slow disk operations in both the MP3->DAC feeder and the user interface, sometimes at the same time.
  3. Not lock up the user interface during I/O.
A stack of "virgins"!

At the same time, we agreed that we should not walk into the common trap of engaging in "job splitting". That is, to split up jobs in small chunks so they don't take so long to finish. The problem with job splitting is that it makes the code flow very complex.

After much scratching our collective heads over how to make a primitive "three-task" system be able to do everything we wanted without resorting to complex job splitting, we finally came to the conclusion that we were heading down the wrong road:

We need threading.

Even though a scheduler adds complexity, it makes the rest of the code so much more straight-forward that the total net result is less overall complexity.

To keep it simple, we decided to use a cooperative scheduler. That is, one in which the threads themselves decide when scheduling is performed. The big gain from this, apart from making the scheduler itself less complex, is that we don't have to worry as much about making all code "multithread safe".

Affording ourselves the luxury of threads, we soon identified four basic threads:

  • Disk thread, performing all disk operations
  • UI thread, handling the user interface
  • MP3 feed thread, making sure the MAS is fed with data at all times
  • I2C thread, handling the sometimes very relaxed timing of the I2C bus

Threads use message passing between them and each have a message queue associated to it.

There's much fun to be had with these things!

In addition to the threads, we need a timer interrupt with the ability to send messages to threads at specific intervals. This will also be used to scan the keys of the jukebox and handle key repeat detection (when a key has been pressed for a number of ticks).

None of these things are, of course, written in stone. Feel free to comment, discuss and argue about them!

We are currently 89 subscribers to this list. If you want to get more deeply involved in what's going on, I encourage you to:

  • Subscribe to the rockbox-cvs list, to see all code that goes in.
  • Join the #rockbox channel on There are always a couple of us in there.

I have written a set of guidelines for contributing code to the project. Take a look at them in CVS or here: CONTRIBUTING


Page was last modified "Jan 10 2012" The Rockbox Crew