Wiki > Main > SummerOfCode2012 (compare)
Difference: SummerOfCode2012 (r12 vs. r11)
If you're a developer with ideas, please note them here.
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. We also recommend checking out the rockbox source code, compiling a build for you device, and generally familiarizing yourself with the code you're interested in. This will help you produce an informed project proposal.
Please use the template from GSoCApplicationTemplate2011 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.
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):
Rockbox has a fixed point AAC decoder based on libfaad. Unfortunately libfaad is not particularly fast even after extensive optimization. For example, on ARM7TDMI, Rockbox uses over 120MHz for 64kbps AAC-HE. The Helix ARM decoder uses only 60 MHz - a difference of over 100%. FFmpeg provides a much more efficient, but floating point decoder. In this project, a student would explore combining some or all of the ffmpeg decoder into Rockbox, either replacing or augmenting libfaad. The ffmpeg decoder would be converted to fixed point and optimized for embedded decoding. The resulting improvements to Rockbox would reduce power consumption and provide the open source community with substantially more efficient embedded MPEG codecs.
Rockbox has a single MDCT function used in AAC, WMA, WMA Pro, Vorbis, AC3, Cook and ATRAC3. The performance of this library thus impacts a number of formats. While the current implementation is algorithmically efficient (close to minimum total instruction count) it is not well optimized for many CPUs because it aims to have minimum possible memory use for low memory targets. It could be greatly improved on newer ARM devices at the cost of some memory. Additionally, most ASM is heavily biased in favor of ARMv4. ARMv5/6 or Coldfire implementations would greatly improve performance on other targets.
Some new rockbox targets run on MIPS CPUs. In this project, a student would review various ARM assembly optimizations added to MP3, Vorbis, AAC, WMA and FLAC and then port them to MIPS. This would ensure that rockbox's exceptionally fast codec library can be used efficiently on MIPS CPUs, and also provide fast embedded MIPS codecs for formats that currently lack them.
Rockbox has a fixed point MP3 decoder based on libmad. Unfortunately libmad is not particularly fast even after extensive optimization. For example, on ARM7TDMI, Rockbox uses 38MHz for 128k MP3. The official ARM decoder uses 29MHz, a difference of almost 25%. Other libraries exist for decoding mp3, each with their own strengths and weaknesses. In this project, a student would explore the performance of each of the major components of our decoder and then evaluate possible replacements in other codec libraries (ffmpeg, etc) or implement their own code based on algorithms in the literature. The goal would be to produce a decoders using either the best known algorithm or best known open source code for each step in the decoding process. The resulting improvements to Rockbox would reduce power consumption and provide the open source community with substantially more efficient embedded MPEG codecs.
Note: this project involves comparing highly optimized libraries and identifying small improvements. Several of the proposals below involve much less well optimized libraries that will be substantially easier to optimize, are likely to be better suited to less experienced students.
This project would finish the WMA Voice decoder and port WMA Lossless from ffmpeg to Rockbox.
Due to the open scope of this project idea we would rely on the student to provide project goals.
Rockbox currently has limited video playback via the mpegplayer plugin. This can play MPEG program streams containing MPEG-1 or MPEG-2 video and MPEG audio.
There are many areas where Rockbox's video playing capabilities can be improved, including support for more video/audio codecs, support for different container formats, making use of hardware video acceleration or integrating video playback into Rockbox's core audio playback engine (allowing mixed audio/video playlists).
An initial step that any project to enhance video playback in Rockbox would be to refactor the existing mpegplayer plugin to implement an infrastructure for multiple video/audio codec or container format support.
Some specific proposals:
A student undertaking this project could propose to implement a number of the smaller features proposed above, or a single large feature.
The precise skills depend on the tasks the student decides to undertake for this project.
The goals would depend on the precise enhancements the student proposes to implement.
However, we would expect a summer's work to involve implementing the infracture for multiple audio/video codec and container support and then adding a new video codec. In addition, existing Rockbox audio codecs (e.g. AC-3 and AAC) could be implemented as part of this project.
Rockbox uses a plugin architecture for some of its features, mainly codecs and what are actually called "Plugins" in the user interface. Currently, only one plugin of each type can be loaded at a time. There is a demand to be able to run multiple plugins in parallel. This is not possible currently, because plugins are compiled at a fixed address at the start of the plugin buffer. The project would mean to create a framework which allows plugins to be compiled and linked with relocation information, to be resolved at load time. It would probably also mean finding new file format for the plugins, such as coff or elf (or look at elf2flt). Of course part of the job is to adapt the core plugin loader to handle more than a single plugin and a new file format too.
Reasons for this ability to run multiple plugins are:
This project requires a basic understanding of the compile-assemble-link chain and to get known to various alternative binary formats. It may even require changing an existing format to fit our needs.
The mid-term goal would be to have the new loader working and demonstrated, but not necessarily fully integrated yet.
By the end of the summer, we'd expect to have both plugins and codecs working with the new system, as well as working visualisation plugins for the WPS, and possibly USB plugins.
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 suffers licensing problems. Look at FS#7660 for futhter reference. Another possiblity could be flite.
During SummerOfCode2010 there was efford taken to port flite to rb and it was proven non doable. 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. Look at this ML thread for further reference.
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.
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:
This is not a trivial task, particularly because it probably means fiddling with different code layers like the storage API, directory and tag cache.
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).
Apple has a number of accessories that allow control over devices remotely. he 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:
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.
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:
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.
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 making big improvements on existing services.
r12 - 10 Mar 2012 - 17:14:34 - FrankGevaertsRevision r12 - 10 Mar 2012 - 17:14 - FrankGevaerts
Revision r11 - 27 Feb 2012 - 14:17 - AmauryPouly
Copyright © by the contributing authors.