Rockbox mail archiveSubject: Re: GSoC project: Standalone audio library
Re: GSoC project: Standalone audio library
From: Sean Bartell <wingedtachikoma_at_gmail.com>
Date: Thu, 26 May 2011 22:55:41 -0400
On Thu, May 26, 2011 at 12:05:28AM +0100, Dave Chapman wrote:
> 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.
That's one of the many features to be considered.
> 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?
I'm going to investigate other libraries' APIs when designing
librbcodec, including ffmpeg.
ffmpeg and librbcodec have very different focuses: ffmpeg is optimized
for speed on desktop computers, while librbcodec is optimized for small
embedded devices. This leads to various implementation differences. The
main one is that librbcodec is fixed-point, while ffmpeg is mostly
Making ffmpeg work in embedded software would mean adding clutter and
maintaining both floating-point and fixed-point code at the same time,
which I doubt the ffmpeg maintainers want to do. It might be useful to
have one library act as an interface for the other, so embedded software
can use ffmpeg for codecs librbcodec doesn't have.
> 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.
If it's used by Rockbox, it's theoretically useful for other software as
well. There'll probably be a big config.h with lots of #defines (e.g.
for IRAM use), and any project going for maximum efficiency will need to
edit the file.
Received on 2011-05-27