#903211 - Pastie

Embed
Download
Raw
A A A
Plain text April 04, 2010
8:16PM EDT Report abuse
About You

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'm attending at the HTW Berlin (University of applied science,
    http://www.htw-berlin.de/). I'm in the second year, focusing the Bachelor of
    Engineering in my course of studies, Computer Engineering. I definitely plan
    to get the Master of Engineering after that.
4.  I own many DAPs, including some Sansas (e200, Fuze (v1 and v2), Clip) and
    two Samsungs (YH-925 and YH-J70). I also own a FriendlyARM mini2440
    development board which runs Linux and Rockbox natively. This board will
    help me during this project.
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.
    I also touched many other areas with often small but noticeable changes.
6.  I want to work on Rockbox because it's 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, some of its features even outperform
    desktop media player or applications shipped with mobile devices which
    creates the desire to run Rockbox on those too. This is what my project will
    be about.
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'll be able to work at
    least 50 hours per week, possibly even more.
    The semester break begins on July, 27th. I'll somewhat busy with exams for
    the 2 weeks before (exams starting on July, 12th),
    but I can schedule my exams so that they don't 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 am familiar with the development environment
    and most the tools involved.
10. I have a good grasp of the C programming language and the ARM assembly
    language. I have also worked with other scripting languages such as shell
    scripts, perl and ruby.
11. I have a good deal of open source experience. As previously mentioned
    I've been participating in Rockbox for three
    years and I participated in two DevCons. 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've contributed code to the
    plugins and Geany itself and hang around in Geany's IRC channels for quite
    some time.
    Both project got me accustomed to the open source culture. I'd even say I
    fell in love with it because it's so fun to collaborate with other awesome
    hackers to produce good code and a useful program which can be used by
    everyone, freely.

About Your Project

Abstract :

Recent DAPs show that it's not sensible to replace the the entire factory
OS with Rockbox on them. They have features which Rockbox cannot offer, don't
make much sense given the platforms Rockbox currently runs on or it's simply
difficult to port Rockbox to them. However, many of today's mobile devices, most
prominently smart phones, come with the ability to run third partly
applications.
Therefore, it makes sense to run Rockbox as an application on them, extending
the already feature-rich OS with the stunning playback features, codec support
and plugins of Rockbox. The goal of this project is to lay the groundwork for running
Rockbox as an application and to port the application to a desktop OS and
a mobile device.

Detailed Description :
We have seen see the desire among the
entire Rockbox community for a Rockbox application for several years now.
People do not want to miss Rockbox on their smart phones for example. That led
to experiments with the simulator. While the simulator works everywhere where
SDL works, the experiments have shown that the simulator itself is not suitable
for an application because it simulates an existing port. An application should
rather be tailored to the device it runs on. The experiments have also shown
that SDL is rather slow, making the simulator not snappy enough to run on a
mobile device. The goal should be to not depend on a possibly slow SDL port,
instead we want to use the OS capabilities directly.
An attempt was made in 2008, but it wasn't quite successful. We also received a
GSoC application for 2009. The experience made will help me through the project.

During the project, the application will be ported to a platform. This port
should not be the end of the Rockbox application effort. In fact, this port
should serve as an example port to aid others porting the application to other
platforms.

Describe your project in as much detail as possible (only relevant details, no need to mention e.g. that you will set up a build environment) Try to subdivide the project in logical sub-projects, and describe them separately

I plan to divide the project into 2 major tasks:

1:  Refactor the existing simulator code into a new port and creating an SDL
    Application

    Here I will port the uisimulator code into the target tree. I will split it into
    an application and a simulator part, moving simulator specific bits out of
    the application and create a real SDL port comparable to the existing ARM or
    Coldfire ports.
    This also means revisiting other code areas which have preprocessor conditionals
    for simulators, reconsidering the need for them and whether they are
    suitable for the application as well, for instance, enabling
    architecture-specific codec optimizations for the sdl application.
    I plan to port resulting application to my mini2440 board which runs
    Linux. I can directly compare it to a native Rockbox installation. If I
    manage to get a similar user experience under the application
    I consider this part as succeeded.

2:  Build a native application without SDL upon the groundwork laid above,

    The goal of this task is to remove the need for SDL, but instead to rely on
    functions and libraries provided by the OS for threads and drawing.
    Special care about threads has to be taken because Rockbox heavily relies
    on cooperative threading, while the native OS threads are often of a
    preemptive kind.

    I'll probably target Android, but other platforms such as Maemo (Linux) or
    Windows Mobile are possible too. I will probably buy a device
    specifically for this task but there is also a useful emulator available.


Benefit to the Rockbox project

The benefit to the Rockbox project would be immense. It opens the door to many
more use cases and users as it removes the biggest hurdle when porting to a
new device: Being able to replace the OS by running custom code. As many devices
nowadays are locked in some way, it's increasingly difficult to port Rockbox
as a firmware replacement. With the Rockbox application it will also make sense
to run it on a phone, as it seems highly unlikely that Rockbox will be able to
make calls ever. We can provide the Rockbox application as an easy-to-install
app for mobile devices which greatly extends the user base. Surely it will also
attract new developers to our project which don't necessarily come from
embedded systems, which is always good (and the idea behind GSoC after all).

Milestones and Project plan (this can follow the task subdivision, but this is not absolutely necessary)

Project plan/Milestones(=*)
 -  Move stuff from uisimulator to the target tree and split out
    target-simulator specific stuff
 -  Revisit existing simulator-related conditional compilation,
    introduce it for the application where needed
 -  Create a SDL application with application specific settings and defaults
 *  The SDL application can be built and provided as a downloadable zip
    file which can be unzipped and run on a PC/my mini2440 board
 -  Begin the port to a mobile device (likely an Android-based one)
 -  Compile and run the SDL application
 *  Sound plays
 -  Replace SDL by OS provided functions and libraries
    (might consider portable and lightweight 3rd party libraries if the OS
    provided stuff is not sufficient; those would be possibly shipped with
    Rockbox)
 *  SDL dependency removed (Rockbox application runs natively)

Subdivide the working period in several parts, not more than one to three weeks long. For each of these parts, describe what you plan to do in this time, and which deliverables will be finished at the end of it. We know and understand that there will inevitably be deviations from these time estimates, but please try to make them accurate as possible.

    Preface: I am aware that the first period represents somewhat less total
    work. This is explained by the fact that I'm still studying in that period
    with exams at the end. I'll have a lot of free time to work on GSoC in
    the second coding period.
    Until May 24:
        I plan to collect information about possible target systems and their
        quirks before the actual coding period begins. I'll communicate with
        the community, collecting opinions and ideas about what to implement
        (and what not to implement). This is in preparation of the actual work.
    May 24 - May 30:
        In this period I'll move the uisimulator/ code into
        the target tree. I expect this to be a relatively simple job as
        it does not include much coding. However, many files need to be moved
        and updated, potentially forgetting something. That is why about half
        of the time will be spend maintaining the functionality of the
        simulators.
    May 30 - June 4:
        I'll be working on factoring-out simulator-specific bits into a
        subdirectory of the sdl target. Again, time will be spend on keeping
        the simulators working.
    June 4 - June 9:
        I'll skim through the sources, revisiting existing simulator
        conditional compilation. My long Rockbox experience will help me
        alot here since I'll be able to quickly identify the rationale behind
        most preprocessor conditionals. I'll be asking the my mentor or
        community for comments in case I'm unsure.
    June 9 - June 24:
        With the data collected in the previous period, I'll be working on
        making the Rockbox application compile based on an existing
        simulator target, preferably one with a large screen and touchscreen
        interface which enables the use of the mouse.
    June 24 - July 1st:
        Finish the application by removing the target simulator behind, but
        instead - together with the community - work out suitable settings
        and UI related decisions to form a real application.
    July 1st:
        This is my suggested deadline for deciding on what mobile device
        to port the application too.
    July 1st - July 23rd:
        - Prepare for and taking exams -
        That will keep me quite busy so I don't expect much coding work
        to happen here. However, I'll be spending a bit of time on diving
        into the target device (playing around, skimming docs) so that I can
        get straight into the porting effort after exams are finished.
    July 23rd - August 1st:
        I'll be beginning to poke with the actual target port here. I'll be
        working out the exact details of what is needed in order to make the
        Rockbox application using the information I collected before the
        actual coding phase and between the exams. I'll most probably work
        with an emulator, if available, before touching the real device.
    August 1st - August 3rd:
        In this period I'll be working on porting the SDL application to the
        device (if SDL is available - it's for Android). If the SDL port works
        well, this shouldn't be much of a problem. If not, I won't be
        concentrating on it very much, as porting the SDL application is not
        the goal. The goal of this exercise is to get actually Rockbox
        running as an application on the real target device (with music playing)
        for the first time.
    August 3rd - August 12th:
        I'll be working on removing the need for SDL and calling OS functions
        and libraries where possible and useful. This mostly concerns drawing
        and threads. After this a preliminary version of Rockbox will run on the
        device.
    August 12th - August 16th:
        At this point, finishing up and polishing the port will be needed so
        that a package or zip can be distributed.
    August 16th:
        Firm pencils down date. I plan to be finished at this point. On this
        date a redistributable package for the Rockbox application should be
        available for at least 2 platforms (a desktop OS, a mobile device).

    1. Do you expect that your project will need more work or maintenance after the GSoC period ends? What do you think are the chances of you sticking around and helping out with that and perhaps other projects? 
    After GSoC:
        I definitely plan to stick around for maintainence work and future
        improvements and maybe even ports. I'm a long time Rockbox participant
        of Rockbox, and GSoC will not change my affiliation
        and passion for the project. I'm quite confident that I will succeed,
        but no matter of the result, I'll be around after for sure!

You and the Community

    1. How do you propose you will be keeping everyone informed of your progress, problems, and any questions you might have over the course of the project?
    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'm already
    familiar with Git, I'll commit my progress into my public git repository
    which can be browsed via a web interface. Last but not least, I'll 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's important for me to keep
    the Rockbox community informed and involved.

    2. What expectations do you have of your mentor(s) as well as the community itself?
    I have no additional expectations from my mentor or the community. From my
    past experience with it, I know that if I have a problem or a question then
    I can kindly ask and eventually I get an answer.

Misc

    1. Is there anything else that we should know that might have us lean in you/your project's favor? 

    At the end of this application I would like to express my confidence that
    I'll 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'm able to skip phase of getting used to our code
    and start working straight away.
16262 characters / 271 lines