Bluetooth-alsa
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:
- Write an alsa plugin that communicates with the daemon through
D-Bus and which can send it audio using unix sockets
This plugin will accept audio and send it on to the daemon or to
the speakers depending on what destination has been set up.
The plugin inside alsa-plugins/{ctl,pcm}_sco.c would be a good
reference for how to integrate with alsa. These are currently for
talking to the headset daemon that transfers sco audio over hci.
- Enhance the headset service to do a2dp services
The a2dpd daemon from plugz is the best example for signaling and
talking with the headset.
- Build reference D-Bus gui for audio controls
A simple gui should be written to choose to connect to bluetooth
headsets or disconnect and use built-in audio. This may also be where
pairing is done but depends on the bigger picture of how the ui for
pairing is done.
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.
D-Bus
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.
- Audio transfers
- Advanced interaction, such as indicating an incoming phone call
- D-Bus API for managing connections and routing
- Audio stream and connection management
- Audio stream to built-in soundcard or SCO-over-PCM passthrough
- Audio and control communication with bluetooth audio devices
- D-Bus messages and events
- Uinput keypress events
- KEY_PLAY
- KEY_PAUSE
- KEY_NEXTSONG
- KEY_PREVIOUSSONG
- HAL events (adapter presence changes)
- 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.
- pulseaudio client protocol
- advanced signaling such as indicating a call
- d-bus controls to activate/deactivate bt audio devices
- controls to open/close streams, possibly a socket passing file descriptors
- wired audio and also sco-over-pcm audio paths
- control connections to bt devices
- d-bus events
- uinput events for avrcp messages
- HAL events (adapter presence changes)
- SCO-over-PCM link
- a2dp and sco-over-hci audio data