View difference between Paste ID: f7627ef8a and

-
+1. ABOUT ME
 
 
 
 1.1 What other names or aliases do you go by/we should be expecting to see you as in IRC/forums/mailing lists?
 
 mtarek16 : is the username I register with in any website.
 MT : My name on IRC (Was : MTee).
 Mohamed Tarek : is my real name and my name on the lists.
 
 1.2 Which school/college/university are you currently attending? What year are you in and what is your current major/focus?
 
 University : Ain Shams (in Cairo,Egypt)
 Faculty : Engineering
 The system in my faculty goes like this : first a preparatory year, then the student selects one of the following departments
 (Electrical, Mechanical, Civil or Architectural). after two more years, the student selects a major from his department.
 As for me;
 Department : Electrical
 Major : I'll still select my major the next academic year but it will be Computer and Systems Engineering.
 
 1.3 Do you currently own a DAP? Have you owned any in the past?
 
 Yes; I own a Sansa e250 and I have had it now for about 2+ years.
 
 1.4 Have you previously been involved in Rockbox? If so, how?
 
 Once I bought my DAP, I found rockbox and installed it. But it took me a while to actually get involved.
 What I've done so far is basically language-related :
  - Added the Arabic glyphs to (helvR12) font with the help of Marcoen Hirschberg.
  - Initiated the Arabic lang file, again, with the help of Marcoen, and translated about 125 more strings
    for the next release.
 
 1.5 Why do you want to work on Rockbox?
 
 Briefly : I LOVE it! Using rockbox for such a long period made me very enthusiastic about it. I almost never met some friend, who
 owns a DAP without talking to him about rockbox. Besides, it's a kind of an embedded system ; working on rockbox, besides being
 very much fun, is actually relevant to my future major and career.
 Also, I would rather contribute to a proect that has proven to be of much benefit to me than to a random software I barely use.
 
 1.6 Where are you located, and what between which hours do you anticipate being active and available to work on your project?
 
 I live in Cairo,Egypt.
 Timezone : GMT+2 (DST in summer : GMT+3).
 My final exams will start around the 20th of May, and last for about a month or slightly more.
 So, Before the start of my vacation I'd be able to work on evenings from sunday to wednesday. The rest of the week, I'd be able to work during the morning.
 When the vacation starts, my work will be mainly during the morning.
 
 1.7 How many hours per week do you have planned/scheduled for your gsoc work, should it get accepted? Are there any vacations, events, or other time-
 
 consuming unrelated stuff going on? (nothing here will reject your application, however we just do not want to be surprised)
 
 Before the exams I may be able to work an average of 3-4 hours/day which sums up to 21-28 hours/week.
 During the exams I can't promise more than 2 hours/day (~14hours/week). I maybe able to do more than that, which would be good. However, I don't want to
 say I'm going to be able to work for X hours/day and find out later that I can't.
 I conceive this project as a summer job so, once the vacation starts, I plan to work for 8-9 hours/day,
 but I'll take friday off so this will be 48-54 hours/week.
 
 1.8 Have you built Rockbox yourself from source before? If not, you will want to go ahead and set up an development environment and build Rockbox at least
 
 once as your qualification task will involve this basic task. See the "For Developers" section on DocsIndex for help (and don't be afraid to use the IRC
 
 channel if there are other issues).
 
 Yes I have built it from the source more than once, during the testing of the font and the lang file.
 As I said I have a sansa e200 so I was building for a arm based target.
 
 1.9 What programming experience do you have, and in which languages? If those don't include C, please tell us how you intend to deal with this lack. If
 
 possible, please point us to a code sample that you wrote that you feel demonstrates that you know what you are doing.
 
 I can code in BASIC, C, C# and a little PHP. C is my strength though. I spend some of my time writing code for PIC uC's (using C).
 But I haven't written "large" programs for a microcontroller yet. Most of them were simple.
 I have also written a sudoku solver, and it was actually able to solve basic boards. More functions still had to be added to solve the intermediate
 and hard boards, but I lost interest in it and abadoned it.
 Another program I wrote was a logic minimizer using Quine-McCluskey algorithm
 (about 1000 lines of code, link to the code : http://pastebin.com/f2c119d1c ); it's very similar to espresso in the way it works, because I wrote for
 the sake of learning not for innovation.
 
 I have some comments on the code I sent, though. I know it's not perfect, and needs a lot of tweaking but I don't have much free time to
 do that. If I were to write this logic minimizer again I would do the following :
  - Design an ADT based on a linked list instead of using a dynamic array of structs.
  - Take the function declarations to 2 separate header files : one for I/O functions one for the algorithm-related functions,
    main() would probably only loop thorugh three functions : TakeInput(); ProcessInput(); ProduceOutput();
  - Add more comments.
  - break down large functions into small ones. I appreciate the paradigm of building a big project out of smaller building blocks.
    This program, however doesn't convey this appreciation :).
 
 My skillset may be not that impressive, but I hope this project would hone them and teach me more skills.
 
 1.10 Do you have any previous open source experience that you can point to?
 
 I believe by experience you mean being active with the community, so based on that I would say no, only rockbox. But if you mean being involved
 by any means in an OSS, even just using them, then yes, ffmpeg, vlc and linux.
 I had to go through the source of ffmpeg and vlc to be able to work on the project, and I'm a linux user.
 
 
 
 2. ABOUT THE PROJECT
 
 
 
 2.1 ABSTRACT
 
 
 Rockbox already supports a wide range of codecs, it still, however, does not have support for RM. The main aim of the project, thus, is to add
 support for RM format, and to have enough fixed-point decoders to handle the commonly available RM files.
 
 
 
 2.2 DETAILED DESCRIPTION
 
 
 2.2.1 TASK DESCRIPTION AND SUBDIVISION
 
 
 I expect the project to go as follows :
 
  - have a complete, working demuxer :
 
        The demuxer was already started by Dave Chapman (linuxstb on IRC). He sent it to me and I continued working on it. Thus far
        the available demuxer can parse a RM file and write the raw audio data to an output file.
        More work will need to be done to make the demuxer do the following :
        1. Identify the correct decoder and send audio buffers to it.
        2. produce output files as needed with the decoded audio.
 
  - have a fixed point Cook decoder :
 
        libffmpeg already has good decoders, so the plan will be to extract a decoder, write a proof-of-concept application that that
        would produce a decoded output from a cook-encoded input then start converting all the calculations to use fixed point arithmetic.
 
  - have a standalone rm-wav converter :
 
        At this point it should be fairly easy to have a standalone converter application that would take in a RM file and produce an output
        WAV file. This was implied in the previous point but I wanted to make it clear. Once this program is done, I should start porting it
        to rockbox.
 
  - Porting to rockbox :
 
        Both the demuxer and the fixed-point codec will then have to be ported to rockbox. This would require me to tidy-up the code to be sure
        it follows the coding style and make sure that the codec is using the memory wisely.
 
  - Adding more decoders (If there's still more time) :
 
        As time allows, more decoders should be added, starting with the next most common ones. Adding a decoder will then go through the previous
        cycle.
        RM can contain one of the following codecs :
        - RealAudio 1.0 (VSELP)
        - RealAudio 2.0 (LD-CELP)
        - AC3
        - Sipro
        - Cook
        - ATRAC
        - RealAudio Lossless Format
        - LC-AAC
        - HE-AAC
        - MP3
        Of which the following have open-source decoders available as part of libffmpeg :
        - RealAudio 1.0 (VSELP)
        - RealAudio 2.0 (LD-CELP)
        - AC3
        - Cook
        - ATRAC
        - MP3
        MP3, AC3 are already supported by rockbox, they are just mentioned here as they could be found in a RM container.
        If cook, AC3, RA1 and RA2 are implemented, rockbox will be able to play almost any RM file.
 
 
 
 2.2.2 BENEFIT TO THE ROCKBOX PROJECT
 
 
 I have asked on the developers list and in the IRC channel about continuing this idea as a rockbox project. The replies that I got clearly indicated
 that such an idea would be of great use, one of the replies were, and I quote, " .. more codec support is always welcomed.. ".
 I know that not many audio files out there are in RM, but still, there are enough files that RM support would be a significant addition
 to rockbox.
 I for one would be really pleased to have rockbox play RM files because :
 1. Occasionally, I find myself in a situation where I need to convert a RM file to be able to play it.
 2. This would give rockbox another edge over the current proprietary firmwares.As far as I know, a really small number of them support RM playback.
 
 
 
 2.2.3 MILESTONES AND PROJECT PLAN
 
 
 Almost the same as section 2.2.1
 
  - Working demuxer :
 
        expected time required : 2 weeks.
        goal : to have a fully working demuxer that could identify the available codecs.
 
  - Standalone rm-wav converter :
 
        expected time required : 2 weeks.
        goal : to have a standalone application that would take in a RM file and produce an output wav file.
 
  - Converting the decoder to fixed point :
 
        expected time required : 1-2 weeks.
 
  - Porting to rockbox :
 
        expected time required : 1-2 weeks.
        goal : (this relates to the previous milestone too), to have a cook in .rm sample play on at least one player.
 
  1 week = 1 full-time week (~8 hours/day).
 
 I was encouraged to write out a basic time plan when I read this : "We know and understand that there will inevitably be deviations from these time
 
 estimates, but please try to make them accurate as possible. "
 I'm giving myself enough time to be able to understand what I am doing, but I'll my best to take less time than stated, because the more time I have
 at the end of the coding period, the more codecs I can add.
 
 2.2.3.1 Do you expect that your project will need more work or maintenance after the GSoC period ends?
 
          I believe the project might need a lot of work after GSoC ends. that's because :
          - According to Michael Giacomelli (saratoga on IRC)-who made a wma decoder as a GSoC'07 project- getting some files to play is one goal,
            getting the rest of the files, where bugs show up, is a whole different story. He mentioned that after 2 years of debugging he could still
            find some files that wouldn't play. I expect something similar to that to happen with RM files.
 
          - After cook decoder is mature enough, I'd start to add more codecs.
 
          What do you think are the chances of you sticking around and helping out with that and perhaps other projects?
 
          Really high :). I was already there (idle most of the time however) when I didn't know anything about the code base, so it's very likely
          to expect me to be helping as much as I can after GSoC ends.
 
 
 
 2.3 You and the Community
 
 
 2.3.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?
 
       For questions and problems :
       IRC first, better for a quick, live reply. If by any means I find that the IRC didn't really answer my question I'll head-on to the mailing list
       for more replies and more thorough answers.
 
       For reporting :
       I'll send a weekly update of my progress to the mailing list and to the private e-mail address of the mentor if it's ok with him/her.
       the progress report would contain :
       - work done during the week.
       - problems encoutered and their solutions.
       - next week's work.
       - an estimate of how far I've gone through the project and how much is remaining.
 
 2.3.2 What expectations do you have of your mentor(s) as well as the community itself?
 
       The mentor(s) :
       The main expectation is them being really patient, eager to teach/help me with the things I'll need but yet don't know about; I might ask a lot,
       so I need to feel comfortable to do so, I don't want to be afraid to ask for any reason.
       I'd expect them also to be available via the IRC channel and e-mail.
       The e-mail address doesn't have to be personal, it could just remain on the mailing list.
 
       The community :
       I expect the community to welcome a discussion, and also answer a question if they can.
 
       I wrote those expectations only as an answer to the question, it does not mean that the community it unhelpful whatsoever. I really enjoy
       spending time on the channel, even just to 'watch' a discussion.
 
 
 
 2.4 MISC
 
 
 2.4.1 Is there anything else that we should know that might make us like you or your project more?
 
    - I'm not a quitter. So it's very unlikely that I'd abandon the project.
    - You wouldn't worry about how to keep me involved after the program ends. I already want that, and I'd be more than happy to be a committer
      when I'm good enough.
    - I still have more ideas for rockbox, and, as I stated, it's relevant to my future career, so I would do my best to help enhance it.