Attached is my current draft of my buflib application. I very much
welcome comments on it.
NOTE: It's not finished, I plan to elaborate few pieces a bit more (the
"compaction scheme" thing in particular), however I think the final
project schedule will probably be very similar to what's in that draft.
Again, please comment on it.
About Me
1. My name is Thomas Martitz, you can always contact me at
thomas.mart...@student.htw-berlin.de which I check multiple times per day.
2. My nick on IRC and the forums is kugel, I am subscribed to the rockbox-dev
mailing list with my thomas.mart...@student.htw-berlin.de address.
3. I am attending at the HTW Berlin (University of applied science,
http://www.htw-berlin.de/). I am in the third year, focusing the Bachelor
of Engineering in my course of studies, Computer Engineering. I definitely
plan to get the Masters of Engineering after that.
4. I own many DAPs, including some Sansas (e200, Fuze v2, Clip) and
two Samsungs (YH-925 and YH-J70). I use Rockbox as an application on my
phone (HTC Legend) as well. I also own a FriendlyARM mini2440
development board which runs Linux and Rockbox natively.
5. I have been involved in Rockbox since 2007, hanging around, hacking on
it and simply enjoying being part of the project since then.
In early 2009 I was given commit access, enabling to submit code directly
to the SVN repository. I worked in many areas, but most notably the
Sansa AMS port where I wrote and optimized some drivers and the skin engine
where I was the first to use it outside of the WPS with the base skin.
Last year I ported Rockbox as an application for Android as part of
GSoC 2010. This was very successful. Since then I maintained that port and
helped new Rockbox as an application ports to raise.
I also touched many other areas with often small but noticeable changes.
6. I want to work on Rockbox because it is a fun project in all aspects and a
compelling and useful piece of software. I have actually been working on
with passion for quite some time and I will continue to do so.
The features it offers compared to the OF are exciting. In fact, with some
of
its features it even outperforms some desktop media players or applications
shipped with mobile devices, which is why I use it every day on my phone.
But it is clear that Rockbox has a few limitations, due to memory
or processing power constraints which I find interesting to resolve with
small footprint solutions.
7. I live in Berlin, Germany. The timezone is GMT+2 (CEST). I am available to
the community and my mentor in the morning when I use my laptop at the
university and in the afternoon and evening at home.
8. During the semester, my working hours would probably depend on when I
come from the university, but I prefer something between 14:00 - 22:00.
I hope I can work some 35-40 hours per week, but that will depend on the
work load the studies put upon me.
During my semester break I can work from 10:00 - 22:00, which means I would
devote my entire spare time to the project if needed. I will be able to
work at least 50 hours per week, possibly even more.
The semester break begins on July, 23rd. I will somewhat busy with exams for
about 2 weeks before (exams starting on July, 11th), but I can schedule
my exams so that they do not collide too much with my project.
There is another exam period late September and I can choose between both
periods for each exam. The semester break ends on October, 1st.
9. I have built Rockbox a lot. I amvery familiar with the development
environment and most the tools involved.
10. I have a strong experience with the C programming language and the ARM
assembly
language. I have a solid experience languages such as C++, Java and VHDL
as well as scripting languages like shell scripts, perl and ruby.
11. I have a good deal of open source experience. As previously mentioned
I have been participating in Rockbox for four
years and I participated in three developers conferences. I also have commit
access to another project, geany-plugins, which is a collection of plugins
for use with the Geany IDE which I use exclusively. I have contributed code
to the plugins and Geany itself and hang around in Geany's IRC channels
for quite some time. I also contributed many patches to Yaaic, my favorite
IRC client on Android.
All three project got me accustomed to the open source culture. I would
even say I fell in love with it because it is so fun to collaborate with
other
awesome hackers to produce good code and a useful program which can be
used by everyone, freely.
About My Project
Abstract :
The proposed project will bring buflib from the plugin library to the core,
enabling dynamic memory allocations.
Detailed Description :
Rockbox has no malloc() in the core. Therefore we have always worked
with static buffers or buffers which can't be freed, resized or allocated after
audio playback started. Since Rockbox runs on a wide range of players with
vastly
different properties, it has become increasingly difficult for us to chose the
right size for buffers.
malloc() is not an option for various reasons. One of the main reasons is memory
fragmentation, since many targets have no MMU to resolve this problem.
However, the plugin library has a promosing allocator - buflib - which is handle
based and can free and compact (move and/or resize) memory on demand. My
project will
integrate buflib into the core as the main allocator for dynamic memory
allocation
needs. This will get us rid of one of the biggest limitations we have to date,
enabling us to implement more awesome features without sacrifying too much
valuable
memory.
The key feature of buflib is indeed compaction. It means it can move allocations
to fill holes caused by freeing memory, which solves the fragmentation issue.
Project plan - Major tasks:
I plan to divide the project into 2 major tasks:
1: Port buflib to the core, as a replacement for buffer_alloc() without
compaction.
This task requires some refactoring in existing code, such as removing
direct accesses of audio buffer and drop-in replacing buffer_alloc() with
buflib_alloc().
Since buflib is a self-contained library, I plan to write test-cases for it
in this task in order to ensure it functions correctly.
Lastly, since I'll be working with almost all non-buffering memory
allocations,
I can collect data and get an overview over what we do exactly with our
memory which will be very valuable for the rest of the project and after.
2: Carefully enable compation, taking care of each buflib user
Compacting will introduce new kinds of problems, likely
hard to debug and with strange symptoms. Therefore this task is expected
to be difficult and rather time consuming.
With the information from task 1, I will develop a scheme which makes
compaction possible with the least pain for developers.
This task will also require to extend buflib beyond its current
capabilities,
e.g. introducing a mechanism to notify buflib user about movement of the
allocated data.
Due to the expected and unexpected problems, this second task is going to
take a longer time.
About the benefit to the Rockbox project
A way to dynamically allocate memory without giving away lots of it due
to fragmentation is sure very beneficial to Rockbox. As previously mentioned,
it enables us to remove some limitations, artificial limits and hacks and to
maximize
costumizability and effeciency. Most importantly, better use of the memory
translates to better battery life because more audio can be prebuffered.
Project plan - Milestones
Project plan/Milestones(=*):
- Ensure correctness of buflib
- Remove all direct audiobuf access, and replace them with buffer_alloc or
other allocation mechanisms if needed
- Replace all buffer_alloc() with buflib_alloc().
* buflib has now exclusive control over allocations in the main memory
(buffering gets the audio buffer via a buflib_alloc() call)
- Develop a scheme for introducing and handling compection
- Extend buflib according to that scheme
- Work on enabling compaction and fixing any regression it may introduce
* Rockbox has now a compacting memory allocator
* Optimized compaction mechanism to be less user-visible
Project plan - detailed description
Preface: I am aware that the first period represents somewhat less total
work. This is explained by the fact that I am still studying in that period
with exams at the end. I will have a lot of free time to work on GSoC in
the second coding period.
Until May 24:
Until the coding period begins I'll look at each possible buflib user
(buffer_alloc() calls, audiobuf[] accessors, ...) and study their needs.
Here I will gather information about what I need to pay attention to
when converting them to buflib_alloc() and when enabling compaction.
I'll also be communication with my mentor and the community about
further
specific needs or expectations about my project.
May 24 - May 30:
In this week I'll spend some time hardening buflib so we can depend
on it for the future. I plan to write some test cases here. This is to
make sure the existing buflib isn't going to surprise me with bugs
over the summer.
May 30 - June 10:
Here I will resolve direct audiobuf[] accesses individually. There's not
to many of them, but each has it's own quirks that need to be addressed
and respected. Some of them will be resolved to buffer_alloc() calls,
others possibly to other mechanisms such as plugin_get_buffer().
buffer_alloc() is preferable since this one will be converted to
buflib_alloc() later.
This period surrounds the DevCon 2011 in London which I attend to. At
the
devcon I'll seek to talk about my project with the other attendees,
which
is definitely a nice opportunity.
June 10 - June 14:
During this period I will be convert buffer_alloc() user to
buflib_alloc().
Without compaction, this should be a mostly a drop-in replacement.
Since buflib returns handles, for the time being we will query the
data pointer right after allocation to minimize the changes. In the
end result we want to avoid querying for the data pointer anyway.
June 14 - June 25:
I'll be developing the scheme for enabling compaction, paying attention
to the information collected and considerations mentioned by the
community.
June 25 - July 6:
I'll work on implementing compaction.
July 6tht - July 23rd:
- Preparing for and taking exams -
That will keep me quite busy so I do not expect much coding work
to happen here.
July 23rd - August 1st:
I'll finish the compaction work. By now we should have a working
compacting memory allocator. It may still have quirs but it should be
generally usable
August 1st - August 16rd:
Here I'll making the buflib less user visible and optimize it for
most efficient behavior.
August 16th:
Firm pencils down date. I plan to be finished at this point. I'll
clean up documentation, test-cases and generally make sure the
project is a success.
After GSoC:
I definitely plan to stick around for maintainence work and future
improvements, such as adopting more code areas to the new buflib
mechanism.
As I am a long time Rockbox participant
of Rockbox, and GSoC will not change my affiliation
and passion for the project. I am quite confident that I will succeed,
but no matter of the result, I will be around after for sure!
Me and the Community
1. Proposals for keeping contact with the community and information sharing
To keep the community and my mentor informed, I will create a dedicated
wiki page where people can follow my progress. In addition,
I plan to have a weekly report email on the mailing list. As I am already
familiar with Git, I will commit my progress into my public git repository
which can be browsed via a web interface. Last but not least, I will be
around on IRC to ask and answer any questions related to my project.
After all, even if I am a single student doing this project and the coding
working, the result will be inevitably a collaboration of several people
(which is a good thing) which is why it is important for me to keep
the Rockbox community informed and involved.
2. Expectations for my mentor(s) and the community itself?
I have no additional expectations from my mentor or the community. From my
past experience with Rockbox and GSoC, I know that if I have a problem or
a question then I can kindly ask and eventually I get an answer.
Misc
At the end of this application I would like to express my confidence that
I will be able to complete the project successfully. I know a lot of the
traps a student can fall into during this project since I know the code base
quite well. This good knowledge about the code base is also what will save
me a lot of time because I am able to skip phase of getting used to our code
and start working straight away.
