|
Rockbox mail archiveSubject: Re: GSoC project: Standalone audio libraryRe: 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. I agree. > 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 floating point. 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. Thanks, Sean Bartell Received on 2011-05-27 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |