Wiki > Main > SummerOfCode2009 (compare)
Difference: SummerOfCode2009 (r33 vs. r32)
If you are considering applying to Rockbox (or any other organization, in fact), you may want to have a look at this wiki page: http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents . It contains a lot of good advice about what you should expect during the Summer of Code and helps you create a good proposal.
Please use the template from GSoCApplicationTemplate2009 as a guideline when submitting your application. Be aware that if your application appears acceptable, we will be issuing a (what should be) simple qualification task based upon your project proposal at some point that will show a basic technical capability to start on your project.
Add your suggested projects here to be reviewed by the applying students. These are only ideas and suggestions, students are free to make up and describe their own project when they apply. If you are a student planning on applying, please come into our IRC channel on FreeNode and talk to us about it!
NOTE: This is not a general wish list for Rockbox features. Don't add a project here without discussing it with the Rockbox developers first.
Rockbox currently supports speaking by premade voice clips. Some lightweight text-to-speech engines (for example, espeak (version 1.26 is the last one which is GPLv2+) or flite) might be suitable for integration into Rockbox.
Currently Rockbox input is a limited button based system--no pointing device mouse/touch type thing. Getting the touchscreen going would be a big boost to those currently unsupported targets with touchscreens
(JonathanGordon edit: I dont know what the touchscreen state in the lists is, bu it used to be almost workable before we moved to the "grid button" scheme which I think is on automatically now... I have ideas about a customisable touch screen interface in the WPS but dont really know if it will all be a big enough project for GSoC )
Create a stand alone command line version of the rockbox codec api functions so that rockbox codecs can be compiled and tested outside of rockbox, much as ffmpeg codecs can be tested from the command line. Then optimize codecs in order to fit into certain memory or CPU usage goals. Introduce standard, optimized library functions for common tasks to complement the existing IMDCT library (such as bitstream parsing, huffman decoding, etc). The goal of this project would be to improve the performance and memory usage of rockbox codecs, while making them accessible to other embedded projects.
Rockbox has a fixed point WMA Standard decoder, and ASF parser, but there is no suitable WMA Professional decoder. During GSOC2008 a floating point WMA Pro codec was implemented for ffmpeg. This project would port the codec to rockbox by removing all floating point code, stream lining memory usage, and optimizing for ARM playback.
Lua is a powerful, fast, light-weight, embeddable scripting language. It's used in many projects and its library can easily get extended to support external functions (i.e. the plugin API). There's already a patch for this in the tracker.
This would mean adapting mpegplayer to accept various container formats, and combinations of audio/video codecs. For the purpose of GSoC it would probably be acceptable to add a single additional video codec, and the framework for files of either format and various combinations of audio to be played.
Port ScummVM to Rockbox.
USB work is pretty low-level, and it requires access to specific players. The USB specification is available at http://www.usb.org/developers/docs/usb_20_122208.zip. There is a reasonably short introduction at http://www.beyondlogic.org/usbnutshell/usb1.htm
While MSC support works well for many people, MTP can have some advantages :
There does not seem to be any open source MTP device implementation. The libmtp project has a host side implementation.
The USB Audio device class would allow:
USB Audio requires isochronous transactions. Support for these is not yet available in Rockbox, and is not possible on all controllers
The human interface device is mainly used for keyboards and mice. It would be interesting to allow using the DAP as a sort of keypad, and as a general default class if the DAP is only connected for charging.
HID requires interrupt transactions. Support for these is not yet available in Rockbox, but should be trivial to implement
The USB Communications device class encompasses various communication systems. The most important ones for Rockbox are Serial and Ethernet. There is a partial USB Serial implementation for Rockbox, but it only works with linux. Ethernet support would open up many possibilities, as the DAP can be networked with the host. To be useful, this would of course also need a TCP/IP stack (LWIP is probably a suitable one), and one or more plugins to actually use it. USB Serial is mainly useful for debugging
Once more than one or two device classes are implemented, binsize concerns will start to become important. Allowing class drivers to be implemented as plugins would make it much easier to add new ones.
Specifications for all USB Device Classes are available at http://www.usb.org/developers/devclass_docs
Since virtually all new DAPs coming to market contain an ARM core, a well working ARM emulator would be extremely useful to future ports. An emulator could be used to help reverse hash/encryption algorithms used in many retail firmwares (such as Apple, Sandisk, Creative players), to help determine addresses of memory mapped hardware, and to optimize codecs by allowing more detailed analysis of memory/IRAM/etc. A simple but only semi-functional Windows emulator exists for the Sansa E200 series which emulates much of the PortalPlayer hardware. It currently can boot some builds of rockbox, but is not stable enough to be very useful. This project should resume work on the emulator (or pick another to use), first getting it to run rockbox or a retail (Sandisk, Apple, etc) firmware without instability. This would involve a process a lot like porting rockbox, but in reverse. Starting with the drivers in Rockbox, one would need to implement the hardware devices they interact with until rockbox (and hopefully the OF) could run as if on real hardware. These would include LCD controller, various internal memories, buttons, and DACs.
Currently the Rockbox Utility suffers many complaints regarding accessibility. Either adapting all of its functionality to be accessed through a CLI interface, or fixing the accessibility issues currently extant and improving the user inteface for blind navigation and use.
A separate tool for creating the Rockbox database, modifying the tagnavi file in a manner understandable to those not wishing to learn filter syntax, and creating and validating playlists for use on device (making sure the paths to the files lead to actual files on the device, and attempting to locate them by filename when the folder structure does not match, possibly).
A handy bit of advice for prospective mentors: http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors
Mentors should sign in to http://socghop.appspot.com and create their own profile. Then, they can request to be a mentor for Rockbox.
r35 - 22 Sep 2009 - 18:16:24 - DominikWengerRevision r33 - 05 Jun 2009 - 20:30 - BryanJacobs
Revision r32 - 05 Jun 2009 - 16:22 - RobertKeevil
Copyright © by the contributing authors.