Bluetooth audio for Linux

Overview | History | Future work | Download & build | Credits | Contact us

If some form of these patches makes it upstream, we'll be in better shape for voice support on linux.

Some of the work below has started to make an appearance in bluez cvs under utils/audio and in the wiki. Our current list of objectives:
There are still limitations in the architecture that make complete desktop or handheld integration impossible. Audio applications should not have to be individually configured back and forth between wired and wireless audio. We want a VOIP call in progress to be able to be easily switched to and away from a headset, another complicated interaction.


The BlueZ team has recently taken the approach to integrate with the desktop using the desktop bus. This allows for messages to the user to indicate for example when a bluetooth adapter becomes available or a new connection needs to be authorized.

D-Bus holds a lot of promise for dynamically routing audio between combinations of built-in and bluetooth audio.

Single-daemon architecture

The new design merges SCO, A2DP, and built-in (wired) audio devices from the application's point of view so there is a single default system-wide audio device.

Connection management and advanced controls like AVRCP are communicated using D-Bus and, optionally and to a lesser extent, the uinput device.

The diagram shows the daemon doing all bluetooth I/O but we haven't ruled out Fabien's latency optimization to have the daemon manage a file descriptor for the SCO channel that the plugin uses. In this case the audio plugin would in effect be doing direct bluetooth I/O.

  1. Audio transfers
  2. Advanced interaction, such as indicating an incoming phone call
  3. D-Bus API for managing connections and routing
  4. Audio stream and connection management
  5. Audio stream to built-in soundcard or SCO-over-PCM passthrough
  6. Audio and control communication with bluetooth audio devices
  7. D-Bus messages and events
  8. Uinput keypress events
  9. HAL events (adapter presence changes)
  10. SCO-over-PCM link (on embedded devices, the sco audio stream typically uses this path)

Pulse architecture

In systems that use an audio server like pulseaudio, we want to avoid having audio pass through two daemons, so the audio xfer agent portion of btaudiod has to be something that can be used from an audio plugin.

Is it really necessary to have a gui for selecting and activating audio devices that is separate from padevchooser? Or could paired devices appear in padevchooser even if they are not connected? If it's needed, the separate connections gui would be used to activate a previously-paired set and when the bt control connection is successfully made, HAL and D-Bus signals would be emitted. Then the device would appear to padevchooser.

Can pulse discern between a multimedia client (writing only) from a voice client (reading and writing the audio device)? On a combo bluetooth headset, these are done through different profiles and we have to know before opening the audio stream which type it will be.

  1. pulseaudio client protocol
  2. advanced signaling such as indicating a call
  3. d-bus controls to activate/deactivate bt audio devices
  4. controls to open/close streams, possibly a socket passing file descriptors
  5. wired audio and also sco-over-pcm audio paths
  6. control connections to bt devices
  7. d-bus events
  8. uinput events for avrcp messages
  9. HAL events (adapter presence changes)
  10. SCO-over-PCM link
  11. a2dp and sco-over-hci audio data