Rockbox mail archiveSubject: GSoC project: Standalone audio library
GSoC project: Standalone audio library
From: Sean Bartell <wingedtachikoma_at_gmail.com>
Date: Sun, 15 May 2011 01:24:52 -0400
I've been accepted as a GSoC student. My project is to separate out
Rockbox's codecs, metadata parsing, and DSP code into a separate
library. I'll add an automated testing suite, make the library usable by
other embedded software, and perform some other improvements. My project
will make codec development easier, and hopefully external projects will
use and make contributions to the library.
My name is Sean Bartell (wtachi) and I've been using Rockbox for months
on my Clipv2. I've built Rockbox before, but this will be my first
contribution. I live in Cary, NC, US.
Although coding doesn't officially start until the 23rd, I'm going to
start some now to compensate for family vacations during the summer.
I'll start off by doing some refactoring on the codecs. In particular,
codecs have their own implementations of endian conversion, bit reading,
windowing functions, huffman decoding, etc. and I'll change some of
these to use a common implementation in codeclib. The main purpose of
this task is to get familiar with the code and development process, so
I'll just spend 1-2 weeks working on the low-hanging fruit.
The library will include the decoders, encoders, metadata parsers, and
DSP code (resampling, equalization, and timestretching). I'll need to
remove dependencies on the rest of Rockbox. There will be a fixed set of
functions that must be implemented by the library's user, similar to the
way codecs currently interact with the rest of Rockbox through struct
When the first steps are done, it will be possible to build the library
on Linux without using the rest of Rockbox. I'll make a simple demo
program that can play music and use all the features of the library.
The library will need a name, of course. "librbcodec" seems fine to me,
although I also grepped a dictionary and came up with "libwaRBle". Maybe
"warble" can be the name of the test program?
This will be my project's most direct benefit to Rockbox. I plan to
write a Python driver that will decode each test file and do an exact
comparison against known correct output. For new test files, where
there's no known output, I'll use fuzzy comparisons (e.g. PSNR) against
other libraries and tools. The driver will also check the results of
seeking, and test the other library features.
It may be possible to test platform-dependent assembly with qemu or
another emulator. I'm also interested in checking coverage and using
other techniques, like Valgrind.
External projects and licensing
The initial focus will be on getting the library working, not on a nice
API. In order to appeal to software other than Rockbox, I'll change the
API to make it cleaner and more flexible. I'll examine other codec
software (both proprietary and open), talk to interested projects (if
any), and make a big list of features the ideal library would have.
This includes anything from documentation (essential) to reading lyrics
files (feature creep). We can then figure out which items are feasible
and important enough to implement this summer.
Something other projects will be particularly interested in is the
license. Almost all the relevant code in Rockbox is licensed under
GPLv2 "or any later version". This means the library can be used by any
GPLv2- or GPLv3-compatible license, but the result must be distributed
under the GPL. Standalone programs (e.g. Android apps) should be fine
with this, but it will prevent libraries like libavcodec or the Android
SDK from using our codecs. Relicensing would solve this, but it probably
isn't worth the effort unless we know libavcodec or Android are
interested. In any case, it seems best to use the LGPL for the new code
The rest of the summer
Depending on how extensive the API changes are, there might be time left
at the end of the summer. I can spend this time making other
improvements to the library, such as performance optimizations.
Received on 2011-05-15