Home About Community Download Documentation Planet

Google Summer of Code: 2012


Official timeline.

The next important deadline is for students to apply: April 6: 19:00 UTC

Important information


The official website is at: http://www.freedesktop.org/wiki/Software/PulseAudio

API documentation is at: http://freedesktop.org/software/pulseaudio/doxygen/

The code is at: http://cgit.freedesktop.org/pulseaudio/pulseaudio/


Feel free to contact us on IRC (#pulseaudio on Freenode) or via our mailing list). 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, mentor)
  • Colin Guthrie (coling on IRC, colin AT SPAMFREE guthr DOT ie) (backup admin, mentor)
  • Tanu Kaskinen (tanuk on IRC, tanuk AT SPAMFREE iki DOT fi) (mentor)
  • Peter Meerwald (??? on IRC, pmeerw AT SPAMFREE pmeerw DOT net) (mentor)
  • João Paulo Rechi Vita (jprvita on IRC, jprvita@gmail.com (mentor)


Once you've looked at the ideas below (or have one of your own), feel free to drop by our mailing list or IRC if you'd like some help fleshing things out. Once you're done, 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
  • What you will be finally delivering
  • A short note about yourself
  • Any other notes such as related prior experience (not required, but a bonus), why you think your proposal should be selected, etc. (keep this short as well!)

As a bonus, pick one of our easy bugs, fix it, submit a nice git formatted patch to the PulseAudio mailing list. Include a link to your mailing list post from the list archives in your proposal so we don't miss it.


These are some ideas that the community would like to see pursued, Feel free to contribute your own ideas! The initial list is rough ideas. Use the template in the next section for more concreted ideas.

  • Improve RTP performance (Maarten?) [needs to be more concrete]
  • Add "high priority" events (Arun) [these would preempt passthrough streams, possible notify on all outputs, ...]
  • Efficient resampling (Peter) [esp. on embedded CPUs; maybe fixed ratio sample rate conversion]
=== Project Title (template) ===

'''Brief description:'''

'''Expected results:'''

'''Contact(s):''' <list of people to talk to about this idea, mark potential mentors distinctly>

'''Necessary background:''' <if any, such as networking, assembly, ...>

=== Configurable maximum volume for sinks and sources ===

'''Brief description:'''

Some outputs may be capable of producing louder sound than what is
comfortable. The user should be able to set a limit for the maximum

Some inputs may need software amplification, while others don't.
Software amplification is prone to cause clipping, so it should be
avoided when possible. If software amplification is not needed, it's
useful to be able to prevent it from ever happening by setting the
source maximum volume accordingly.

'''Expected results:'''

Several stages, the more gets done, the better:

 * Ability to configure volume limits with module parameters, and
   enforce those limits.
 * Ability to configure the limits on the fly (without reloading any
 * Make the volume limit configuration persistent so that when
   Pulseaudio is restarted, the configuration is restored
 * A GUI for configuring the volume limits.
   * Preferably implemented by modifying the audio configuration
     tool of the desktop environment of your choice, or by modifying
 * Ability to set a global maximum volume to cap maxmimum s/w gain

'''Contact(s):''' Tanu

'''Necessary background:''' C. For the GUI part some experience from
writing graphical applications would be useful. Pavucontrol is
written in C++ using Gtk.

'''Mentor:''' Tanu
=== Configurable latency for Bluetooth devices ===

'''Brief description:'''

Bluetooth's A2DP profile (the "high quality stereo mode") doesn't
support latency information to be provided by the Bluetooth device
to Pulseaudio. That's a limitation of the spec; we can't fix that.
The effect of this limitation is that the audio-video
synchronization ("lip-sync") is usually not very good. Pulseaudio
currently uses the same hard-coded latency value for all Bluetooth
devices. Assuming that the actual latency stays pretty much constant
for any given device, but varies between different devices (how to
verify this assumption?), it would make sense to make it possible to
configure per-device latencies. This would potentially be useful for
non-Bluetooth devices too, but I can't name any other concrete use
cases right now. Anyway, the feature is general enough to not
require any Bluetooth knowledge or hardware.

'''Expected results:'''

Several stages, the more gets done, the better:

 * Ability to configure the "fixed latency" of devices with module
   parameters. (This is easier than it probably sounds. Applying the
   configured latency should be trivial.)
 * Ability to configure the latency on the fly (without reloading
   any modules).
 * Make the latency configuration persistent so that when Pulseaudio
   is restarted, the configuration is restored automatically.
 * A GUI for configuring the volume limits.
   * Preferably implemented by modifying the audio configuration
     tool of the desktop environment of your choice if the tool
     maintainers want such feature (this feature is quite rarely
     needed, so they might not want it), or by modifying
     pavucontrol. Since this feature is quite rarely needed, a
     custom configuration tool probably wouldn't be too bad either,
     though, if you don't like the prospect of modifying

'''Contact(s):''' Tanu

'''Necessary background:''' C. For the GUI part some experience from
writing graphical applications would be useful. Pavucontrol is
written in C++ using Gtk.

'''Mentor:''' Tanu, jprvita
=== Logging and testing overhaul ===

'''Brief description:'''
PulseAudio provides pretty extensive logging on the server-side, and
some amount of the same on the client side. However, this could
undergo significant improvement. We also have a fairly rudimentary
set of tests, but these cover a very small part of the actual code.

'''Expected results:'''

Improvements to the logging infrastructure, including:

 * The ability to modify the log level at runtime
 * Support for log "categories" (see GStreamer logging for an
 * Filtering of what log categories turn up based on, for example, a
 * A log buffer to allow querying the last X lines of log

Revamp the testing infrastructure

 * Add the ability to run tests and assert on various conditions on
   a PA instance running from the build
 * Run gcov and figure out how abysmal our coverage is
 * Add some useful tests, develop a framework for writing tests rapidly

'''Contact(s):''' Arun

'''Necessary background:''' Mostly C, some bash for testing, hacking
other systems with advanced logging/testing/CI a bonus

'''Mentor:''' Arun
=== Better HDMI support ===

'''Brief description:'''
HDMI provides a number of nice features that we can use to make a
better experience in PulseAudio. Part of it is coming with the new
jack detection work, but there is still some room for improvement.
This project is not very complex, however, and will likely take 1/2
the time give for SoC, so should be clubbed with some other task.

'''Expected results:'''
 * ELD parsing (can reuse some existing work for this)
 * Set up sink formats based on this
 * Set up sink # of channels, and channel map (possible?) based on
 * Parse latency information and expose this for A/V sync

'''Contact(s):''' Arun

'''Necessary background:''' C, access to a device with HDMI output
and an HDMI receiver (TV, etc.)

'''Mentor:''' Arun
=== Improved RAOP Support (Airtunes™) ===

'''Brief description:'''
Colin introduced initial RAOP support some time ago but the
implementation still needs work to make it universally useful. This
project would see an upgrade to the newer Airtunes2 protocol, a new
timing and buffering model and support for additional hardware
including newer models of the Airport Express, AppleTV and e.g.
Denon 4311 or Phillips SoundCurve. Some initial work has been done
by Christophe Fergeau (author/maintainer of libgpod) to investigate
and update to Airtunes2 protocol. This work is far from complete,
but could form a starting point. Analysis of existing solutions,
including protocol analysis, will likely be needed as the protocol
is mostly undocumented.

'''Expected results:'''
 * Analysis of the Airtunes2 protocol on existing implementations
   and creation of protocol documentation
 * Convert code to use Airtunes2 protocol
 * Implement a robust timing and buffering model for reduced
 * Ensure timing information is accurately relayed to applications
   such that GUIs showing song timing information, lyrics etc. are
   all in sync even if there is a higher overall latency.
 * Become completely sick of the student's chosen test song that
   will no doubt be played repeatedly ad infinitum during testing.

'''Contact(s):''' Colin

'''Necessary background:''' C, Wireshark/Protocol Analysis, Access
to Airtunes h/w - preferably several different models.

'''Mentor:''' Colin
=== GUI Interaction/User Feedback ===

'''Brief description:'''
!PulseAudio is a daemon and thus GUI interaction is normally left
for other people to integrate as they see fit. However, support for
specific forms of GUI interaction could be facilitated more easily
via a !PulseAudio module. Most Linux desktop environments now
support the Desktop Notification specification which provides an
infrastructure for showing passive/unobtrusive notifications to the
user and for collecting simple feedback (i.e. answering basic

'''Expected results:'''
 * Provide a mechanism to let the user know a new (never seen before
   device) has been plugged in and ask if they want to use it by
 * Ensure that remote-sink detection modules (using zeroconf) are
   converted to offer an interactive mode (i.e. show the user they
   have found something but ask if they want to connect and, if
   necessary, prompt for authentication).
 * Adjust volume control GUIs to know when Pass-through-mode is
   active for a given sink and thus volume controls are disabled.
 * Integrate work appropriately into the Desktop Environments of
   GNOME and KDE
 * ''Note'': Ubuntu uses a fork of the Desktop Notifications
   specification and uses a different feedback specification:
   Indicators. While it would be nice to support this variation,
   emphasis should be first placed on official upstream
   implementations. It would be nice if the final implementation was
   sufficiently flexible to work with both systems.

'''Contact(s):''' Colin

'''Necessary background:''' C, D-Bus, GTK, Qt, GUI/HCI

'''Mentor:''' Colin
=== Extend HTTP Protocol ===

'''Brief description:'''
Web-centric desktops are more common place these days, as are home
media solutions where control and command is performed via smart
phones. Since Pass-through support was merged in !PulseAudio 1.0, we
have used json-c which facilitates the used of JSON formatted data
in some selective places. The HTTP protocol is currently quite
simplistic, primary designed to push out audio for e.g. UPnP. It
would be nice if the HTTP protocol could be updated to include a
simpler level of "command and control" introspection as the native
protocol (i.e. listing sinks, sources etc. with notification of
changes and the ability to make changes to volume, move sinks etc.)

'''Expected results:'''
 * Review native protocol and design introspection parts of HTTP
   protocol and document.
 * Implementation of HTTP protocol.
 * Create a web based interface to control PA devices and volumes.

'''Contact(s):''' Colin

'''Necessary background:''' C, JSON, HTML/CSS/JavaScript, JQuery
(JQuery Mobile) or similar and perhaps Web Sockets.

'''Mentor:''' Colin
=== Configuration system ===

'''Brief description:'''
This is a much-needed core PulseAudio feature. We currenty store a
lot of configuration in various places -- config files, databases
for various things (volumes, properties, ...). We need a single
configuration API that modules can use and clients can query and
talk to as well. Some discussion on the merits of having
notifications on changes to configuration would be required. dconf
solves a lot of these problems already, but is not supported on
sufficient platforms. One option is to use dconf where supported,
and fallback to ini file-based configuration where it is not (so we
lose the ability to be notified of changes on these platforms).

Step one in this task would be to get consensus on the backend. Step
two would be to write up documentation for an API if one needs to be
designed, post to list, get consensus. Next is implementation, with
test cases, and moving over config options to it. Finally, if time
permits to hook up some common config options in pavucontrol. There
is a work-in-progress
[[[http://piratepad.net/BLGxYG2lf3]|discussion]] about this.

This is a somewhat hard project, involving a lot of community
interaction and pretty good software engineering skills from the
start. On the other hand, this is core API and a great way to
experience the Real Thing™ as far as open source development goes.

'''Expected results:'''
A configuration API that modules and clients can use, proper
documentation for developers, automated test cases, and some
implementation of actual use of this API.

'''Contact(s):''' Arun, Colin, Tanu

'''Necessary background:''' C, general configation mechanisms
(simple databases like tdb/gdbm, ini files, gconf/dconf/ ...) would
be useful too

'''Mentor:''' Arun, Tanu