Google Summer of Code: 2013

Important Dates

Official timeline.

Students can start submitting applications: 2013-04-22.

Deadline for student applications: 2013-05-03.

List of accepted students announced: 2013-05-27.

General PulseAudio Information

Homepage: http://www.freedesktop.org/wiki/Software/PulseAudio

Code: http://cgit.freedesktop.org/pulseaudio/pulseaudio/

Mailing list: http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

IRC: #pulseaudio at irc.freenode.net (webchat)

Bug tracker: https://bugs.freedesktop.org/ (list of open PulseAudio bugs)

Contacts

Feel free to contact us on IRC or via the mailing list (see the links above). We don't bite! (Note about IRC: there's no guarantee of a fast response. Some of us are present on the channel 24/7, but that doesn't mean that we pay attention all the time. So if you contact us via IRC and you don't get a quick reply, don't think that we're ignoring you, just hang around on the channel until you get an answer or try again later.)

Arun Raghavan (Ford_Prefect on IRC, arun AT SPAMFREE accosted DOT net) (admin)
Colin Guthrie (coling on IRC, colin AT SPAMFREE guthr DOT ie) (backup admin)
Tanu Kaskinen (tanuk on IRC, tanu DOT kaskinen AT SPAMFREE intel DOT com) (mentor)
Peter Meerwald (pmeerw on IRC, pmeerw AT SPAMFREE pmeerw DOT net) (mentor)
David Henningsson (diwic on IRC, david.henningsson AT SPAMFREE canonical DOT com) (mentor)

Applying

Once you've decided which project idea suits you the best (pick an idea from the list below or one of your own), write up a proposal. Having the following bits will likely help make a coherent proposal:

A description of the project
A break-down of the tasks involved and possibly what you will not be covering (more detail is good)
A schedule that describes how much you expect those tasks to take time (if a task takes much more than a couple of weeks, it should probably be split into subtasks)
A short note about yourself
Any other notes such as prior open source contributions (not required, but a bonus), why you think your proposal should be selected, etc. (keep this short as well!) The application that you submit is only one factor when we think whether you should be accepted instead of someone else. You can greatly improve your chances of getting selected by demonstrating in practice that you have the necessary skills and that you're a nice person to work with. Join the mailing list and the IRC channel and be active. Pick some suitably small task to work on (nothing wrong with big tasks either, if you have lots of free time). Ask questions and send patches. There's a list of "easy" bugs that can be useful when thinking what to work on.

Ideas

Project Title (template)

Problem statement: What problem does this project solve?

Suggested solution: A rough outline of what needs to be done. If this is very detailed, this inevitably ends up being copied as the project plan (not necessarily verbatim), which makes it impossible to judge whether the student knows what he or she is talking about. I'm not sure if this is a huge problem, though. Ideally, the student capability would mostly be judged based on the pre-selection contributions.

Contacts: List of people to talk about this idea, mark potential mentors distinctly.

Necessary background: What skills are required/beneficial?

Potential mentors: List of people who volunteer to mentor this project.

Better JACK Configurability

Problem statement: JACK is a sound server for so called "pro audio" use cases, such as music production or live performances. Many people want to run PulseAudio on top of JACK, so that JACK has direct access to the sound card and PulseAudio accesses the sound card through JACK. When running PulseAudio on top of JACK, the default configuration creates one two-channel sink (i.e. output device) and one two-channel source (i.e. input device) for JACK inside PulseAudio. If the user wants something different, the only way to change the configuration is to edit the configuration file by hand, which isn't particularly user-friendly. Furthermore, the configuration parameters are very limited: only the number of channels per device can be changed, and it's not possible to have different number of channels for input and output. (Actually, to be more accurate, it is possible to have different number of channels for input and output, if you load module-jack-sink and module-jack-source manually instead of relying on module-jackdbus-detect, but then you lose the convenience that module-jackdbus-detect provides.)

Things that users might want to configure:

channels for input and output separately
disabling input or output altogether
multiple input or output devices
modes for quickly switching between several configurations Suggested solution: The set of parameters that module-jackdbus-detect supports should be expanded to cover the given use cases. As the responsibilities of module-jackdbus-detect grow beyond bare detection, it might make sense to rename the module to simply module-jack.

The switchable modes should be implemented as card profiles. Currently, the JACK code doesn't implement a card object, so one task is to implement a "JACK card".

To achieve user-friendliness, there should be a GUI for changing the settings. Just implementing the JACK card with a good default set of profiles would go a long way, because the existing GUIs already support changing card profiles.

Implementing only the JACK card would probably make this project too small to fill the whole summer, so there could be some extra GUI options added for JACK: for example, the "auto-connect" option could be exposed in a GUI (maybe separately for each device or card profile). It's a simple boolean option that is already supported, but changing the option value requires editing the configuration file by hand. Adding new run-time-editable configuration options is far from trivial: the GUI code needs to be written, the client API needs to be extended, the IPC protocol needs to be extended and persistent storage for the options needs to be implemented.

Contacts: Tanu

Necessary background: C for PulseAudio code. C++ for pavucontrol code (the preferred GUI application to modify is pavucontrol).

Potential mentors: Tanu

Resampling Improvements

Problem statement: PulseAudio aims to match the sample rates supported by the hardware to the sample rates requsted by the application. This process is called resampling and is quite CPU intensive. PulseAudio resorts mostly to external code to provide resampling: speex, ffmpeg, libsamplerate. Speex seems unmaintained, ffmpeg now provides a library interface (libav) and code duplication is unnecessary (we have a copy of the ffmpeg resampler in our source tree). libsamplerate is GPL. Lightweight, high-quality and optimized resampling code is desirable.

Suggested solution: Assess available audio resampling code, performance-wise and feature-wise. Implement interface to enable resampling provided by libav and drop code copied from ffmpeg.

Contacts: Peter

Necessary background: C for PulseAudio, signal processing, possibly assembler for SIMD optimization (SSE, NEON).

Potential mentors: Peter