|
|
Google Summer of Code 2013Information for studentsIf 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.Project ideasNOTE: 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 optimisationOverviewRockbox'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 OptimizationRockbox 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.Skills needed
Suggested goalsDue to the open scope of this project idea we would rely on the student to provide project goals.Potential mentorsImproved codec and playback module separationOverviewIn SummerOfCode2011 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
Skills involved
Potential mentorsUSB CD emulationOverviewRockbox 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.Skills involved
Suggested goalsThe 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.Potential mentorsUSB AudioOverviewThe 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.Skills involved
Suggested goalsThe 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):
Potential mentorsUSB MTPOverviewThe 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.Skills involved
Suggested goalsAmauryPouly 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.Potential mentorsText To SpeechOverviewRockbox 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. During SummerOfCode2010 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.Skills involved
Suggested goals
Potential mentorsRockbox Playback Test DriverOverviewRockbox 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.Skills involved
Suggested goals
Potential mentorsMake multi-volume targets look like a single volume (like unionfs on linux)OverviewMany 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:
Skills involved
Suggested goalsA 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).Potential mentorsARM EmulatorOverviewSince 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.Skills involved
Suggested goalsAn 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.Potential mentorsRockbox web/online servicesOverviewThere 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:
Skills involvedCurrent rockbox webservices are written with php, but other languages are also possible for new services.
Suggested goalsA 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.Potential mentorsCandidate MentorsCandidate Backup mentorsr10 - 02 Apr 2021 - 20:46:07 - UnknownUser
Copyright © by the contributing authors.
|
