Google Summer of Code 2009

---

What?

Rockbox has been accepted to participate in GSoC 2009: the project page is here.

---

Accepted projects for GSoC 2009

Project name	Student	Mentor	Code
Rockbox Support for Wavpack Hybrid Compression	Bryan Jacobs	Dave Chapman
Adding RM support to Rockbox	Mohamed Tarek	Michael Giacomelli
Port of Rockbox to the Sansa View	Robert Keevil	Paul Louden
Make Rockbox a musical instrument	Wincent Balin	Peter D'Hoye
Allow USB class drivers to be implemented as plugins + Implement Human Interface Device (HID)	Tomer Shalev	Frank Gevaerts

You can find a summary for those projects at this page.

---

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 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.

---

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. 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.

Core

Text to Speech in core.

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.

Touchscreen

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 )

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.

• A fork of rockbox as an application already exists, and could be used as a starting point for an official port: http://www.motorolafans.com/forums/showthread.php?t=11349

• 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.

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:
  • http://developer.gnome.org/projects/gup/
  • http://www.betterdesktop.org/
  • http://openusability.org/

• The implementation part of this project would require the student to implement at least some of the recommendations of the study.

Codecs

Codec Library and Optimization

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.

Fixed Point WMA Professional Codec

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.

Plugins

Support for the Lua scripting language

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.

Multi-codec architecture for mpegplayer

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.

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.

DocumentViewer

• 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.

• _Comment by MartinArver: scummVM is written in c++. Read this scummVM developer discussion for their thoughts on a Rockbox port. See also http://wiki.scummvm.org/index.php/HOWTO-Backends.

USB

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

Support for additional USB device classes

• Rockbox currently supports MSC. There's also partial support for serial.
• Other device classes like MTP, Audio, HID, or full CDC support would be really nice to have

Media Transfer Protocol (MTP)

While MSC support works well for many people, MTP can have some advantages :

• Immediate updating of the database
• Setting time and date from the host PC
• No possibility to corrupt the DAPs filesystem by unplugging unsafely
• (Possibly, needs further research) Copying files to the DAP while being able to use it normally

There does not seem to be any open source MTP device implementation. The libmtp project has a host side implementation.

Audio

The USB Audio device class would allow:

• Using the DAP as a "USB Sound Card"
• controlling various sound settings from a host-side mixer application
• (for players with FM radio) using the DAP to get radio on the host

USB Audio requires isochronous transactions. Support for these is not yet available in Rockbox, and is not possible on all controllers

Human interface device (HID)

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

Communications device class (CDC)

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

Infrastructure to allow USB class drivers to be implemented as plugins

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

Support for USB Host

• Some players have USB Host capable hardware (H300/Euro, Gigabeat S, Gigabeat F). Rockbox currently makes no use of it. These controllers implement either the OHCI (H300, Gigabeat F) or the EHCI (Gigabeat S) specification
• This project would include writing at least one actual hardware driver (depending on which DAPs the student has access to), MSC host support, and integrating the concept of hot-pluggable USB disks.
• Some iAudio players also have USB host, but there's no documentation available about the used controller.

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, 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.

• 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 utility

Improved accessibility.

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.

Player management tool.

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).

---

Mentors

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.