Google Summer of Code 2013
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 GSoCApplicationTemplate2013
as a guideline when submitting your application to google.
If you're serious about working on Rockbox for SoC, then the best way you can show us is to start getting involved in the project before you make your application - i.e. download the code, hang out in our IRC channel
, subscribe to our mailing lists
, and start submitting patches.
If you are a student planning on applying, please come into our IRC channel on FreeNode and talk to us about it! Please do not contact possible mentors personally at this stage
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.
These are only ideas and suggestions, students are free to make up and describe their own project when they apply.
Audio codec optimisation
Rockbox's core function is audio playback, and the efficiency at which Rockbox can do that has a direct impact on the battery run-time of the portable devices Rockbox runs on - codecs can never run too efficiently.
A project to work on codec optimisation assumes a student with some knowledge of either assembly programming, digital signal processing, or processor optimization, but not necessarily an extensive knowledge of audio compression. Learning about fixed-point arithmetic
maybe needed for some of the codecs projects too. Mentoring will be provided to bring a student's knowledge up to par during the project. If in doubt, ask in IRC about any of these proposals, or come up with one that suits you.
Possible optimisation work includes (among many other things):
Opus Codec Optimization
Rockbox has had support for the new Opus codec in development builds since the official release of the Opus codec by Xiph.org, and in stable releases since 3.13, but although some optimisation work has been done, more work is needed to make Opus support usable on slower devices.
This project can range from algorithmic (plain C) optimizations to target-specific assembly (ARM v5/6/7 or Coldfire). Currently, the main bottleneck is the MDCT, which unlike other codecs, requires radix-3 and radix-5 factorizations. After that, profiling will identify other areas for optimization. The resulting optimizations would reduce power consumption and improve battery life. They should be ported back upstream, where they will benefit many other projects.
- assembly programming
- digital signal processing
- processor optimization
- fixed-point arithmetic
- audio codec theory
Due to the open scope of this project idea we would rely on the student to provide project goals.
Improved codec and playback module separation
there was a successful project to seperate out the codecs into a library. There is now the codec library and a test application it. However, Rockbox' unique audio features don't end at its vast codec support. Its playback engine has a lot of nice features (such gapless playback, cue sheet support, etc). It would be nice to have this playback core available to other applications where the current version of 'Rockbox as an application' isn't an optimial solution. It could also be useful to implement alternative user interfaces while still maintaining the majority of Rockbox' core features.
Specific proposal / suggested goals
- Improve codec library separation (it still has some (minor) rockbox specific quirks)
- Agree with the community what the playback core consits of
- Code refactoring that enables out-of-tree compilation of the playback core
- Build a new library that includes the playback core and the codec library
- Build a test application that can play multiple files/a playlist and can showcase Rockbox' playback related features
- C (GCC / LD)
- Designing software architectures
USB CD emulation
Rockbox has had support for USB mass storage for a while now, on devices that have software-driven USB controllers (as opposed to the hardware USB-ATA bridge chips that were usual in older players).
This project would add support for exporting a disk image file over USB instead of the usual raw disk, and would extend the SCSI handling to present a CDROM device instead of a hard disk. This would allow users to store iso images on a rockbox player, and use the player as a virtual CDROM drive to present those images to a PC, for e.g. recovery or installation purposes.
If time permits, implementing all this as a plugin (and therefore allowing USB drivers in rockbox to be implemented as plugins) would be a worthwhile addition.
The first step would probably be to provide hard disk image exporting, i.e. modifying the existing SCSI code to use a file as a backing store instead of a disk.
After that, the SCSI code should be modified and extended to present an MMC device such as a CDROM or DVD drive.
Of course the necessary settings and configuration code to control the feature must also be added.
The project would add support for using Rockbox target as an USB sound card for playback and recording. In particular it would be useful to handle all possible sound outputs (headphone, spdif, speaker) and inputs (fm tuner, microphone, line-in). Of particular interest would be the ability to tune the fm tuner so that rockbox can appear as a radio receiver if possible. Another useful ability is to use all the possible hardware sample rates and not only 44.1kHz.
The first step would be to implement stable USB Audio playback for at least one usb chip, a good candidate here being the USB ARC controller used in many mp3 players (see list below). The main issue is to implement support for isochronous transfers. AmauryPouly
already wrote some initial usb audio and isochronous support but the code is old, out of sync, lacks many features and needs at least a partial rewrite. The code would need to implement at least the most basics controls like sample rate and volume.
A second step would be to add more features like recording and to handle all possible input/outputs. It could also be useful to implement controls for the hardware features such as balance/treble/bass/3d/... controls and explore how those can be mapped to the USB Audio model and if/how those are handled by the linux/windows drivers and sound systems (windows, alsa, pulseaudio, ....).
A third step would finally be to port isochronous support to other usb chips. Alternatively, the student could add support for USB Audio v2 if this specification appears to have good enough support in recent versions of Windows and Linux and if it brings advantages.
List of MP3 players using the USB ARC driver (not exhaustive):
- Sansa: View, c200, e200
- Creative: ZEN X-Fi2/3
- iPod: mini1g, video, 4g, mini2g, color, nano1g
The project would add support for the MTP (Media Transfer Protocol) to Rockbox as an alternative to UMS (USB Mass Storage). An expected advantage of MTP over UMS is a better integration with the database.
already wrote a MTP driver for Rockbox but the project was never finished and lacks many features. A first step would be to finish this code to have a working implementation of all the basics features. The expected goal is to have the device correct enumerated by Windows and Linux and to have a browsable filesystem.
A second step would be to integrate the database with the MTP code so that the device can report audio tags on files for example and so that files added/removed from the device are also added/removed from the database. The student should also implement support for many more optional MTP commands which allow a more efficient use of the device than bare MTP.
A third step would be to add support for more optional features, like MTP v1.1, or android extensions, or more objects/system properties, or even music playback via MTP.
Text To Speech
Rockbox currently supports speaking menus and filenames by premade voice clips. While this feature is especially for visually impaired people it has the major drawback that it doesn't work with texts that can't get prerendered easily. Examples for such texts are the database view (metadata from the files' tags) and filenames the user changed on the player (until a new voice clip is generated).
Adding a lightweight Text To Speech (TTS) engine would allow Rockbox to overcome these problems. This will make more parts of Rockbox accessible to people that can't use the usual, graphical interface. An engine that might be suited is espeak
(the last version that is GPLv2+ is 1.26). There is proof-of-concept rockbox plugin utilizing eSpeak on the tracker, which was never finished due to licensing concerns which have since then be resolved. Look at FS#7660
for futhter reference. Another possiblity could be flite
there was a failed effort to port flite to rockbox. The problem was massive small sized allocation which comes from the very nature of this type of TTS. Memory fragmentation issue seems to be nonsolvable in this case. See this
for details. Due to this, and the existence of am espeak proof of concept, it seems advisable to base this project on espeak.
- ability to understand and refactor existing code
- optimising code for constrained environments
- analyze the available Open Source TTS engines and identify the one to port
- port the TTS engine to a simple Rockbox plugin. Such a plugin could render a text from a selected text file.
- depending on the time left the TTS engine could be extended to be able of getting integrated into core Rockbox. This would also require adjusting Rockbox to allow usage of voice clips and the TTS system in parallel.
Rockbox Playback Test Driver
Rockbox has an extremely complicated playback engine that can be run on many different devices as well as a PC simulator. Unfortunately, the PC simulator simulates the entire rockbox GUI, making it extremely difficult to reproduce some playback bugs due to timing issues and preventing automated testing. At the same time, the enormous number of features in the playback engine means that most changes seem to break obscure use cases.
Adding a simple interface for scripting rockbox actions would allow easier reproduction of problems identified on target, and allow for automated testing of changes to the playback engine. In this project a student would add the ability to compile rockbox's playback engine on PC without a GUI. Instead commands would be implemented by a test driver, a simple script that sequentially issued actions to the playback engine and recorded the result. Finally, the student would introduce a number of example tests for the playback engine involving common tasks such as changing tracks, seeking through an audio file, and building a playlist.
- ability to understand and refactor existing code
- introduce a test case that replicates at least one well known but currently difficult to reproduce rockbox playback bug
- integrate the test driver into the rockbox build system, so that each change to the rockbox source automatically tests playback for potential regressions
Make multi-volume targets look like a single volume (like unionfs on linux)
Many targets feature both internal storage and a slot for external storage to be inserted (SD card slot, etc). Currently Rockbox shows the SD/MMC/... card as a separate volume (on one currently in development device, it even shows an external card as the main file system and the internal one as a separate storage, because it's can't be written for now).
Ideally, Rockbox could (optionally) show both the internal storage and the external card(s) as a single filesystem. The volumes would of course need to have certain priorities (for filename collisions, writes, etc), however it should be presented to the user and behave as one filesystem. They are several reasons to use such a system, some of them are:
- People often store their music files in an author/album/files hierarchy. Such a system would allow a clean and elegant merge for such users, especially if they don't use the database
- get rid of the ugly hack currently in use (which has its uses but also its drawbacks)
- It could perhaps allow settings override, even booting from an external card. There are lots of potential uses here...
This is not a trivial task, particularly because it probably means fiddling with different code layers like the storage API, directory and tag cache.
- ability to understand complex code (the storage API is not trivial, the directory cache one is tricky in several places and the tag cache is really complex, the interaction between them is important and there are even a few bugs remaining)
- ability to understand one already submitted solution (it's a patch on the bug tracker), take the remarks into account and even reuse parts of it if possible
A mid term goal could be to implement the union file system for the storage API part, not taking into account caching and not investigating too much which parts of the rockbox code have to be updated. The focus would be on functionality, user settings can be implemented later. Special care will be taken about the fact that this is dynamic: the user can eject an external card and the code has to handle that !
The remaining part of the summer could be spent on fixing the directory cache if needed and updating the rest of the code to take the unionfs into account (or not !). Updating the tag cache can also be needed (this part is really tricky, there are decisions to take).
Since virtually all new DAPs coming to market contain an ARM core, a well working ARM emulator would be extremely useful for many aspects of Rockbox development.
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 could resume work on that 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 audio hardware.
Additional goals could include emulating the pipeline latencies of various ARM cores, emulating cache to allow memory profiling 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 may be a better place to start.
An mid-term goal would be for an emulator capable of booting and running one Rockbox target build. By the end of the summer, multiple Rockbox devices would be emulated, proving the multi-SoC capabilities of the emulator.
Apple/Sandisk/etc Various Docks, Remotes, Accessories
Sandisk and Apple have a number of accessories that allow control over devices remotely. In the case of Sandisk, these include the Sandisk Sansa Docking Station, Timex Clock Radio for Sansa, and Altec-Lansing inMotion im413. For Apple, this includes a very large number of devices and several different protocols. The simplest and earliest protocol communicates over RS232 and was reverse engineered many years ago. It is now fairly well supported. Newer devices use more advanced communication protocols, or even USB based communications.
The goal of this project would be to expand the range of devices rockbox works with by some combination of:
- Adding support for newer iPod protocols
- Adding support for Sandisk accessories
- Adding support for USB based iPod accessories (perhaps on non-ipod devices)
- Adding an ipod accessory driver to one of the newer (non-PP) Ipods such as the Nano2G? or Classic6G?.
- Improving the current accessory driver into a more general framework for remote control of devices.
This project is necessarily open ended since it will depend on which hardware a student has access to, their interest/knowledge of USB, and how readily adaptable the various protocols are to Rockbox.
By mid-term, it would be good to understand at least a basic communication protocol.
At the end of the summer, rockbox should be controllable using some new device over a new protocol.
Rockbox web/online services
There are already a number of online services on the rockbox webpage to help the community. For example there is the Themepage to host and automatically check all those user generated themes for rockbox various devices. And there is a page to allow people to easily translate rockbox into their own language.
Improving and or adding additional services could greatly help the community. Possible tasks are:
- Add a service to manage and handle user submitted fmpresets or generate fmpresets from a global radiofrequency database
- Add a service to generate voicefiles using free tts systems.
- Improving the themepage.
- Improving the translation page, and extending it to rbutil.
- Integrating those new services into rbutil.
Of course students can also suggest other usefull services.
Current rockbox webservices are written with php, but other languages are also possible for new services.
- ability to understand and refactor existing code
A possible midterm goal could be to create one service new from scratch.
The remaining part of the summer could be spent developing a second service, or makeing big improvements on existing services.
Candidate Backup mentors
Copyright © by the contributing authors.