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

Rockbox mail archive

Subject: Re: GSoC project: Standalone audio library

Re: GSoC project: Standalone audio library

From: Dave Chapman <>
Date: Thu, 26 May 2011 00:05:28 +0100

Sean Bartell wrote:
> On Sun, May 15, 2011 at 09:22:07PM +0200, Al Le wrote:
>>> The initial focus will be on getting the library working, not on a nice
>>> API. In order to appeal to software other than Rockbox...
>> IMO the API should be laid out first. How else can you say that the
>> library "works"? Besides: a nice API would be a very appealing thing
>> for other projects (other than Rockbox).
> The library "works" if it can be used to test codecs on Linux. The API
> will be *usable* initially, but not necessarily flexible enough for
> other projects. Making it flexible could require significant changes to
> the codecs, and I want to delay that until after the test suite is
> working.

That approach sounds sensible to me - I would find it hard to design an
API in advance.

A few random thoughts about your project:

1) I think that a main goal of your project should be to release a
source package of the library, along with documentation and
example/tutorial programs. i.e. it should be promoted to some degree,
rather than just living in a subdirectory in our SVN. This could
perhaps coincide with main Rockbox releases, to take advantage (at least
in theory...) of the feature-freeze/bug-fix periods.

2) Do you want to enable codecs to be linked statically instead of the
current dynamic loading of individual codecs? I think I would find it
useful to be able to build them that way.

3) What is our relationship to ffmpeg, the main open source audio (and
video) library? Do we want to use an API similar to theirs? Do we want
ffmpeg to be able to use our codecs (would they even want to, instead of
merging our optimisations) ? Will it be a competitor to ffmpeg?

4) I'm suspecting that the hardest part of your project will be create a
library in such a way that it can still be used in Rockbox without any
loss in efficiency, but will also be of more general use. Ideally this
library would be built the same way for Rockbox as for other
applications (i.e. no #ifdefs for Rockbox-specific things), but I can't
imagine how that could work.

I'm looking forward to seeing what your project results in.


Received on 2011-05-26

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy