Waiting for Rockbox 3.0 [LWN.net]

Frequent LWN readers will be well aware that your editor has had some real fun playing with Rockbox, a set of GPL-licensed firmware for digital music players. So the Rockbox 3.0 release, originally scheduled for March 15, is of more than passing interest. This release will offer a number of new features:

The addition of the iRiver H1xx and H3xx players as fully-supported targets. Rockbox works on a number of other players as well (notably iPods and the iAudio X5), but those platforms are not quite ready for a stable release yet.
Several new games, including Jewels, Brickmania, Chessbox, Bubbles, and others. Players with suitable displays can even run Doom.
Support for Unicode and translations to 28 languages.
New codecs, including WAV playback on Archos models and AIFF.
The Tag Cache music database, allowing the user to browse through the collection based on several attributes.
A built-in five-band parametric equalizer.
High-quality, lossless recording on platforms which support it.

There are, of course, many other improvements to the code which help to make it more robust and maintainable, but which tend not to show up on feature lists. Your editor has been running the occasional daily build with good results. This looks to be a release which exposes Rockbox to a wider user base and, in general, draws more attention to the project.

Only one problem remains: it doesn't all work yet. There are a number of codec issues, such as confusion when the user skips around too much. A number of trouble reports with the H1xx models have been posted. Battery life on the H3xx is still far less than with the iRiver firmware. In general, the list of open bugs is on the long side for a project on the verge of a stable release.

The Rockbox developers thus find themselves in a place familiar to many projects: trying to decide when to make a major release. Putting out a buggy system would not endear Rockbox to many of its users, and could set the project back severely. Meanwhile, however, the ongoing feature freeze has brought development to a stop and is creating a fair amount of patch pressure. The developers would very much like to get this release out of the way and move on to working on the new, fun stuff.

Getting releases out is one of the biggest challenges faced by many free software projects. There is a natural tension between the creation of truly stable releases and going on to develop the Next Cool Thing. A number of techniques have evolved as a way of resolving this conflict:

Strict time-based releases, as characterized by projects like GNOME or OpenBSD. Some projects would appear to employ a low-stratum network time protocol server to time their releases to the millisecond. This approach solves the "when do we release?" question, but it will not be suitable for all projects. It would appear to work best when the project is made up of many independent components, any of which can be dropped (or kept at an older version) if they are not ready at release time.
Interestingly, the Linux kernel has moved slowly toward this mode over time with its 6-8 week process.
The "when it's ready" approach. Waiting until no (known) critical-level bugs remain can lead to stable releases, but on an indeterminate schedule. Debian's stable releases highlight both aspects of this approach. The older (2.4 and prior) kernel model also worked this way.
Separate stable and development branches. In theory, this approach allows development to go forward without disturbing the branch intended for the stable release. The pre-2.6 kernel sort of used this approach, except that the development branch was not created until a number of stable releases and updates had gone out. The Mozilla Foundation has used an approach like this as well. The problems here include a certain tendency for developers to go play in the unstable branch and not work on fixing bugs and difficulties in propagating important fixes between the two branches.

The Rockbox developers do not appear to welcome the idea of creating a separate development branch. So some sort of compromise between a timely release and a bug-free release will have to be found. There is some sentiment for putting out 3.0 on Monday the 22nd, with known bugs if need be. The worst of those bugs might subsequently be fixed in an update release shortly thereafter. So, while Rockbox 3.0 will doubtless make many users entirely happy, it may well be a true "dot-zero" release for others.

to post comments

NTP

Posted May 18, 2006 7:54 UTC (Thu) by job (guest, #670) [Link] (2 responses)

That synchronizing to low statum NTP servers would be more exact is a myth. NTP is a peer-to-peer protocol, and makes good use of statistics, so it all depends on how many peers you have. Synchronizing with ten stratum five peers could possibly be even more exact than one stratum one.

Unfortunately, vendors of dirt cheap consumer equipment often only implements the trivial synchronization part of the protocol, properly called SNTP. This helps perpetuate the myths. NTP is one of the most well designed and yet misunderstood protocols. Perhaps that's food for an article in a future (please make it well researched and by somebody who actually knows what he/she's doing) issue of LWN?

NTP

Posted May 18, 2006 12:32 UTC (Thu) by pointwood (guest, #2814) [Link]

May I suggest Poul-Henning Kamp (http://people.freebsd.org/~phk/), he's a real time geek (and a seriosly cool FreeBSD hacker) and a very good speaker - if you ever get the chance to see him speak, I would highly recommend it, you will not be bored :)

NTP

Posted May 18, 2006 15:15 UTC (Thu) by vmole (guest, #111) [Link]

>>>---Joke--->

      Head

(Yes, my ascii art sucks.)

Waiting for Rockbox 3.0

Posted May 18, 2006 15:31 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Recording has been a feature for a *long* time. What's new here is that encoding is possible to some degree on platforms that have no hardware encoding support. This really comes with the software-decoding stuff which is needed for many platforms, including iRiver and the iPods.

(Obviously you still need some degree of hardware support: the iPods won't be recording for a while, if ever, as they have nowhere to accept audio at all.)

iPods?

Posted May 18, 2006 17:12 UTC (Thu) by hummassa (guest, #307) [Link] (1 responses)

IIRC newer iPods can record directly from the headphone jack (you should
plug a mike there, put it seems that some kind of headphones will do)

iPods?

Posted May 21, 2006 17:17 UTC (Sun) by nix (subscriber, #2304) [Link]

OoooOO yes. Lovely. I guess I'll have to stop bitching and look into teaching ROckbox about it then. :)

Waiting for Rockbox 3.0

Posted May 18, 2006 19:20 UTC (Thu) by coriordan (guest, #7544) [Link]

Despite being a long time regular reader, our editor's like of Rockbox slipped by me.

A friend told me about it just recently and it looks really cool. He has an iAudio (an X5, I think). Rockbox mostly works but recording is only available as an unnofficial patch, and the device (specifically the battery, IIRC) gets hot while running Rockbox (but not when running the preinstalled hardware).

Recording is my primary interest, and I've found it hard to find supported hardware. It seems that only the iRiver H1x0 and H3x0 support recording, and they are off the market. I could make a first venture into online second-hand buying...

The Wikipedia entry on Rockbox may be of interest and would benefit from some contributions.