Summer of Code

From The Neuros Technology Wiki

Jump to: navigation, search

Neuros Technology | Products: LINK, OSD, Tablet | Developers

Circle.jpg
NOTE: THIS PAGE IS OBSOLETE. IT MAY HAVE HISTORICAL SIGNIFICANCE, BUT IS OUT OF DATE OR NO LONGER PERTINENT.


SUMMER OF CODE PROGRAM WAS SUCCESSFULLY COMPLETED FOR 2007. See Summer of Code '08

If you are a student looking for a paid internship ($4500 US) doing open source development, the Google Neuros Summer of Code Program is an ideal program for you. You'll get a well paid summer internship (on an american pay scale no matter where you are) with the opportunity to work with companies doing some leading edge software development in an open community fashion.

中文

Contents

Information/Instructions

  1. See Google SoC FAQ for program description and information on what the SoC project is all about.
  2. Check out Neuros OSD Page for information on the product you'll be working on. (all successful applicants will receive an OSD from Neuros)
  3. choose a project from the list below (or come up with your own)
  4. go to the google signup and application page

if you have any questions, please don't hesitate to ask, you can mail questions to us directly at nerochiaro at neurostechnology dot com or visit us at #neuros (on freenode)

Deadline

IMPORTANT: THE DEADLINE FOR STUDENT APPLICATIONS IS 3/26/07

Projects

We have listed some projects that we are interested in mentoring, but of course students can also submit their own brand new ideas if they want and can make them compelling enough.

The programming language for all projects is C unless otherwise specified.

If you are interested, we also have on the wiki the Summer of Code Application form we will submit to google for 2007

Package Manager

Create a package manager for the OSD, intended as both defining a package format and an installer application for such packages. It should allow the OSD to download apps directly over the network and install them without having to reflash the whole memory, kernel and all, as is currently done. It should also allow pre-downloaded packages to be installed from (and possibly to) media cards and UBS disks. The package manager should have a GUI that is usable with a remote controller only.

There are several contstraints, like a read-only root file system, little space in the writeable flash partition and limited text input capabilities. Obviously, you're strongly encouraged to draw upon what's been done for the various Linux distributions, with these constraints in mind. One of the most suitable systems to use as an example comes from the Slax LiveCD distribution, as it is designed to enable "hot-plugging" packages into a system running of non-volatile media

Another side of this project can be that of creating an online repository of packages which can be easily managed and has a web interface for people who want to use a full browser on the PC to find their packages and media cards to bring them to the OSD.

ARM/DSP Bridge

The Neuros OSD uses a dual core ARM/DSP processor from TI. While GNU/Linux runs on the ARM, currently all DSP interaction, including code-loading, video decoding and PCM playback, is through a closed-source interface. This project will create a Linux kernel module for loading code onto the DSP and managing memory transfers, as well as a set of userland utilities to manage code images and a software framework on the DSP to support such operations. Time-permitting, the student could also work on one of several DSP programs to run on the DSP after developing these tools.

The student will get experience writing a Linux kernel device driver, userland interaction with the Linux kernel, interrupt handling and DMA transfers, as well as embedded development on the DSP.

Please note you will be required to sign an NDA agreement with Neuros because, unfortunately, some DSP documentation needed to complete this project is subject to restrictions from the vendor (Texas Instruments). This of course doesn't apply if you already have access to that documentation in some other way (for example through your university). Also, even though the documentation requires an NDA, this in no way limits the license of the code you write; it will all still be open source.

UPnP AV Support

This project should provide support for the UPnP AV standard used by many Windows PCs and embedded devices to share media. This should allow quick and painless discovery and use of shares from Window platforms, and possibly also allow sharing of media from the OSD itself. The student work will include evaluating the various UPnP toolkits that support the UPnP AV standard and use one to implement the support for browsing and playing other media shares (either integrated into the main application or stand-alone if time does not allow).

XMMS2 Frontend

This project will be co-mentored with Anders from the XMMS2 project.

The goal of this is to have a working frontend for XMMS2 running on the OSD. The frontend should be fully usable with the remote and provide good user experience on a television screen. If possible integration with the OSD main application is a feature worth considering. At discretion of the student prototyping or actually developing the frontend can be done in the Lua language (instead of C).

XMMS2 server is already ported to the OSD and integrated with the Neuros Media Server framework, but it might also need some improvements and fixes to allow the frontend to work properly.

Flickr Browser

This project should produce an application that allows navigating some of the information (both graphic and textual) available from Flickr.

Examples of this are viewing recent photos from your friends and your own photos (with automatic login) browsing photostreams, comments, jumping by tags, etc. This is pretty much entirely a UI project, with the goal of showing that browsing Flickr with a remote as input can be a good experience.

The infrastructure to display jpeg images is already in place. It's also possible to assume that much of the setup (accounts, preferences etc) can be done on the PC if too time consuming to do on the device within deadline.

Overnight Transcoder

Not all formats can be transcoded in real time (like Flash Video to MPEG) by the OSD. However having the OSD act as transcoding station that works overnight (or anyway not in real time mode) can be an useful feature. You will need to write an application to schedule and handle these kind of batch transcodings, and its GUI. The necessary infrastructure for decoding and encoding in various audio and video formats using the DSP is already available, but certain formats are not supported by the DSP codecs yet (e.g. FLAC), so you might need to port codecs for the ARM for these.

BitTorrent client

Implementing a BitTorrent client will be a particular challenge due to details of the ARM architecture. The most promising library, libtorrent, does file I/O directly by mapping files to memory. Horsepower is limited on the ARM, so efficiency must be a design goal.

Creativity will be required to achieve an elegant solution for a user interface. Entering torrent .url's with a remote would be... unfortunate for the user, but tight integration with existing trackers must be limited to those sites not legally questionable. "Broadcatching" (RSS feeds of torrents) might be an area worth exploring. Also it can be interesting to explore some integration with an "url shortening" service which produces numeric-only short URLs, much easier to input with a remote.

Other Potential Ideas

These ideas have not been fully evaluated, but seem possible candidates for inclusion on the list of SoC projects. Enterprising students should expand these!

  • Support for alternative container formats (MKV, OGM, etc). This first of all needs evaluation if the support of the container can be done fully in ARM or requries some DSP code. In the latter case it can be a problem to be useful for SoC since vendor support might be needed.
  • Network broadcasting or receiving, using either HTTP or RTSP protocols.
Personal tools