| Home | About | Community | Download | Documentation | Planet |
PulseAudio Development
Documentation
Future Developments
This section will list some future proposals and plans for PulseAudio and it's related helper applications.
Below are listed the development proposals and (where relevant) a link to their tracking tickets.
Support for Apple AirTunes (Airport Express) as Remote Network Sinks
- Status: In Progress - Working, but needs refinement
Developer: Colin Guthrie (coling)
Ticket: #69
Support using Apple Airport devices as network sinks. These can be auto-detected via Avahi.
This will be part of PulseAudio 0.9.14 although the initial support has several limitations (including not being able to automatically reconnect and hogging any devices it finds)
Passive Popup Notifications
- Status: Proposed, some development started
Developer: Colin Guthrie (coling)
Ticket: None as of yet.
As padevchooser is no longer actively developed but did provide nice popups (via libnotify), there is a gap in the market! I am proposing to create a new pulseaudio module that would be started at X11 login (in the same manner as module-x11-publish/xsmp). This module will sit in the background and inform the user when new sinks are detected and other similar events. As libnotify can provide callbacks this interface could be used to provided simple interaction for common tasks (e.g. setting a USB sink as default and moving all streams across to it.
Initial development for this has been started but integration with the GTK mainloop is proving problematic. Lennart has a plan for this so development is stalled until this comes to fruition.
Active 'Default' Sink Support
- Status: Proposal Only
Developer: ??? Maybe Colin Guthrie (coling)
Ticket: None as of yet.
One of the most confusing things for new PulseAudio users is how the setting of the default sink actually works (i.e. a pavucontrol UI issue), but also what setting the "default" actually means. As pulse remembers the sink chosen for a given stream, the "default" is only every used for the initial choice of where to play a new stream. After it's initial play the choice of which sink to play a stream on falls typically to module-stream-restore. For most people this is not what they expect of a "default", therefore this is a proposal to create a module which creates a virtual sink that can attach itself to the users choice of default sink. If the users sets a new default sink, this module will automatically reattach itself to this device. This will allow users to still manually select which sink they want to play a given stream on, but also have an "active" default sink that behaves as one would typically expect a default to behave (where changing the default would automatically appear to "move" the running tracks to that sink.
NB I'm not 100% sure of the practicalities of writing a virtual sink that can change the master sinks it connects to and what this means for e.g. sample rates, formats and channels etc.
Default Sink Priority List with Disconnected Sink Memory
- Status: Proposal Only
Developer: ???
Ticket: None as of yet.
Of many people, the setting of the default (see above) does not work as well as it could when it involves removable devices (be it network sinks or USB auto devices etc.) A common scenario would be similar to the following:
- A laptop with built in sound
- A workstation with USB sound system.
- Want to use the USB system when at workstation and built in when not.
- Do not want to continually tweak preferences.
In order to achieve this goal, this proposal would redefine the "set-default-sink" command and internally handling to work as a priority list where all sinks are rated in order of desirability. As is should be possible to prefer sinks that do not currently exist, it must be possible to record all the sinks that have ever been added to the system and obtain their current status (e.g. active or disconnected). There should also be a method of removing disconnected sinks from this list (e.g. from a housekeeping/tidy up perspective). This approach clearly needs a modification to the protocol in order to provide the necessary information to the client application that will implement the GUI portion of this proposal.
This approach would work well with e.g. a bluetooth enabled hi-fi system such that as soon as you turn it on and it's detected, your music will suddenly move to this device! Ditto for network sinks and USB devices. This would be very user friendly and combined with the notification feedback above, would be quite obvious to the user as to why a sudden change in output device has been invoked (of course the user would have to have chosen this default manually already, but users can be forgetful!)
NB module-rescue-streams could be adapted to use this list as appropriate (although with the changed "default" sink handling outlined in a above proposal, this module would be used much less frequently on a typical setup).
D-Bus Control Interface
- Status: In progress - implementation work ongoing
Developer: Tanu Kaskinen (tanuk)
Ticket: None as of yet.
The grand goal that will hopefully be someday achieved is to split the current native protocol into two parts: server query and control with D-Bus and audio streaming with RTP/RTSP. The D-Bus interface is documented at the DBusInterface page (a draft version is completed - suggestions for improvement are welcome).