Google Summer of Code 2008
What?
Rockbox is officially accepted as a mentor organization for GSoC 2008: the project page is here.
Accepted projects for GSoC 2008
Information for students
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 GSoCApplicationTemplate2008 as a guideline when submitting your application to google
Project Ideas
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.
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.
General Projects
ARM Emulator
- 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, 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.
- Additional goals could include emulating the pipeline latencies of various ARM cores, emulating cache to allow memory profiling, porting to linux, and introducing a general framework that would allow for easy adaptation to the differing memory maps of various ARM cores.
- Another approach would be to have a look at SkyEye to see if we can build upon that. It is designed to emulate various ARM SOCs and could likely be improved to support a SOC used by rockbox. As an added bonus, it can already run Linux for ARM. Given the advanced state of SkyEye, this is probably a very good place to start.
Rockbox as an Application
- Portable devices which allow third party applications to run within the retail OS are becoming increasingly popular. Convert Rockbox to an application that runs on a Windows, Linux or Apple based cellphone, PDA, iPhone, or similar device that allows third party applications.
- Alternatively, Google has proposed an Open Source mobile phone platform called Android which may one day run on many phones using a standard API. Rockbox could be ported to use Google's API and (somehow) linked to a C backend for decoding. An emulator and SDK is available to aid development, and Google has announced their intention to fund open source groups targeting their platform.
- Better suited than Android would be the OpenMoko project, which is a fully open source platform for mobile phones, that already exists and has strong community support.
Interested mentors: DaveChapman
Support for Media Transfer Protocol (MTP)
- This project would be to implement support for MTP, which is currently in the process of being standardised by the USB Implementers Forum as a USB device class.
- Other device classes can also be considered.
Interested mentors: FrankGevaerts
Integration with itunes
- Although not seen as a desired feature by many Rockbox developers, there is a significant number of Rockbox users who choose to use itunes to manage their music, and therefore have two databases and sets of playlists on their ipod. iTunes also stores album art images in this database.
- Rockbox doesn't currently have any knowledge of the database files created on an ipod by iTunes - but the Rockbox database will find the music files via the filesystem and index them via the tags contained in those files (which may or may not be the same as the information in the itunes database).
- This project would need to solve the difficult problem of making use of the information (and possibly writing information such as playcounts) in the itunes database, whilst at the same time not bloating the Rockbox codebase for users not interested in iTunes support.
- It should theoretically also be possible to trick itunes into syncing with non-ipods - e.g. other devices with a Rockbox software UMS driver could fake the identifying information and correctly respond to the itunes-specific SCSI commands.
Build Overhaul
- Remove most of the recursive makefiles to make builds faster (especially on cygwin) and more reliable (due to better dependency tracking)
- Fix the dependency flaws
- Fix the quirks with the generated files, like bitmaps
- Make a new distributed build-master script that makes use of all servers better until all builds are complete
Usability study and implementation
- Rockbox has become quite a complex piece of software. New users are often put off by the user interface and have trouble finding their way, but after a while most get used to it. Still it would be interesting to have someone take a fresh look at things and perform a study on how usability could be improved. Similar/related projects:
- The implementation part of this project would require the student to implement at least some of the recommendations of the study.
Target Specific
Port to a New Target
- Depending on what target, this can be way too much of a task for a summer student.
Implement Support for Apple Accessories
- Requires implementing a low-level serial port driver for the undocumented serial port in the dock connector (and remote connector on iPods which have one), and then integrating support for the higher-level Apple Accessory protocol into Rockbox.
- DavidHall is more than happy to donate hardware to anyone who gets this project from Google. Such products as:
http://home.swipnet.se/ridax/connector.htm
http://www.sparkfun.com/commerce/product_info.php?products_id=8295
http://www.podgizmo.com/index.php?act=viewProd&productId=8
Codecs
Realaudio Support
Realaudio files can contain audio encoded with various codecs (RA1, RA2, G2/Cook, AC-3, ACELP, ATRAC3, AAC, RA Lossless) , most of which have open source decoders available as part of ffmpeg. This project (depending on the current state of similar work in ffmpeg) might need to include conversion of ffmpeg codecs to use fixed-point arithmetic. The project would be to add generic support for the Realaudio container, and implement as many codecs as time allowed.
Interested mentors: DaveChapman
Rockbox Codebase
Playback Engine Re-Write or Major Bugfix
- Would be biggest step towards a first SWCODEC release.
- Could also help unifying the HW-/SWCODEC playback engines.
User Interface (these screens need rewriting/ major work... might need to do more than one to make it a big enough project)
- Recording screen/interface
- Radio screen/interface
- WPS-ify the statusbar (i.e make the statusbar customizable like the WPS. either by using the WPS parser or just icons, or something else)
- quickscreen (viewport-ify it)
- pitchscreen (viewport-ify it)
Plugins
DSP Plugins
- LADSPA-like architecture for audio plugins to process (reverb, filters) or display (tuner, oscilloscope) audio data from different sources (playback, rec, wave generator). This architecture could be used as a basis for an instrument tuner or realtime effects.
- Another idea would be to make plugins for all standard tasks like bass, treble, crossfeed, equalizer and then implement the "sound settings" as a plugin stack, where the user can choose just the plugins he needs to process the output signal.
- Note that if loading more than one plugin at a time is desired, like with the above effects stack idea, a DSP plugin project would also involve creating a relocatable plugin format, since plugins are currently statically linked to a fixed memory location in Rockbox's memory space. This might be a fair bit of work in itself.
Better Video Support
- Rockbox currently has a work-in-progress MPEG (MPEG-1 and MPEG-2) video player. Work to extend Rockbox's video playing capabilities could include: finishing the implementation of MPEG-1/MPEG-2 playback (see PluginMpegplayer for a to-do list), exploring the possiblity of other codecs (e.g. MPEG-4), optimisation of the video codec(s), and incorporating video playback into the core playback engine.
- Features wanted: Basic formatting, links, tables and images (for viewing Wikipedia articles or converting HTML, PDF files for Rockbox).
Port ScummVM to Rockbox.
- Will probably not be feasible on old Archos targets but should work fine on newer targets with larger screens, but might be the most fun on a colour display.
Theme/WPS Editor
- Rockbox has a growing number of theme-related settings (colours, icons etc), some of which can be changed via existing settings, some of which require editing text files. A theme editor would allow users to change these on-target, as well as being able to present a more detailed preview of the settings than can be achieved via standard settings.
- The ability to modify a WPS in a higher-level way than modifying the .wps file in a text editor could also be included - there has long been a demand for a WPS designer application.
- An alternative to writing a plugin would be to write a standalone Desktop application to do the same thing - with the advantage of being able to create a richer UI, but the disadvantage of not being able to use it directly on the device.
Interested mentors: DominikWenger
Database Query Editor
- The Rockbox Database supports advanced customization via the tagnavi.config file, but this is only editable with a text editor and requires a user to enter the queries directly in a custom query language. This project would be to design and implement a user-friendly interface to this functionality.
Framework for localised plugins (plugin translations)
- Rockbox itself can be translated and adapted to the target by the lang file system. We need a similar system for plugin translation.
Infrastructure
Benchmarking tools
- For optimization testing (codec decode timing vs realtime, text draw speed for LCD optimizations, etc).
LLVM Compiler Infrastructure
- Make rockbox compile using LLVM to investigate if it's a viable alternative to GCC (doesn't have a m68k and sh1 backend yet).
Mentors
A handy bit of advice for prospective mentors: http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors
Add yourself here if you are a very much involved Rockbox hacker who would consider to become a mentor for a Summer of Code student:
And when added here, apply "officially" using google's online application here.
Copyright © by the contributing authors.
|
