About Me

1.  My name is Thomas Martitz, you can always contact me at
    thomas.martitz@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.martitz@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.