If you want to write a volume control application, make sure to read this.
Also, make sure to set properties on all PA connections, make sure to read this.
*Finally, make sure you know everything about latency control! *
Talk to PA over D-Bus
Using the native protocol as described is the most common way to talk to PA, but PA can expose D-Bus interfaces as well:
- module-dbus-protocol API - can be used if module-dbus-protocol is loaded. Note that its API has no stability guarantees.
- Device reservation API - if you need PA to give an ALSA sound card to you temporarily
When working on PulseAudio, please mind the Coding Style.
There are several reasons for writing loadable modules for PulseAudio:
- Extended device driver support
- Protocol support beyond ESOUND's protocol and the native protocol. (such as NAS or a subset of aRts)
- New programming interfaces such as XMLRPC or DBUS for controlling the daemon.
- Hooking audio event sources directly into PulseAudio (similar to
For low latency applications such as VOIP: load the VOIP core directly into PulseAudio and have a slim GUI frontend to control it. There is currently a little bit of documentation available on how to write loadable modules for PulseAudio. Beyond this, read the source, Luke! If you are interested in writing new modules feel free to contact the authors in case you have any questions.
- Core API
- Module API
- Module Arguments API
- Threading Model
- A discussion about writing a sink
- Rewinding explained Some things that might be relevant for people hacking on specific modules:
- Brief documentation on volumes
- BlueZ issues/limitations list
- ALSA issues/limitations list