Bluetooth Bluez

James F. Carter, 2007-02-16, revised 2007-09-24

Contents
Introduction
Equipment Chosen
Driver Availability
Initial Setup
Pairing With the Device
Using the Device
Audio Players: Catch-22
Rogue's Gallery of Players
Comparing Wired with Wireless
Bluetooth Profiles

Introduction
I wanted to get a wireless headset for two purposes: mainly listening to music or media content from a laptop running Linux,
a Nokia 770 running Linux, and a media server running Windows Vista and Windows Media Center. A secondary goal was
to do voice phone calls on the Nokia 770 (VOIP) and a Motorola RAZR cellphone. I presently have a wired headset, and I
find the wires to be bothersome. Of the various wireless protocols, Bluetooth is the only one that is credible on all the audio
sources.

Bluetooth refers to a radio communication protocol in the 2.4 GHz ISM band (industrial, scientific and medical, also
microwave ovens). Its governing standard is IEEE 802.15.1. It is a physical protocol analogous to Ethernet (IEEE 802.3)
with an associated collection of "profiles" (see list), which are layer 4 and 5 protocols specialized for use over Bluetooth.

At present there are three variants of Bluetooth in common use: 1.1, 1.2 and 2.0. Versions 1.1 and 1.2 achieve a data rate up
to 721 kbaud (thousand bits per second) in ideal conditions; 2.0 raises this to 2.1 mbaud. All versions can coexist with
competing services such as 802.11b/g (Wi-Fi), with sufficiently low interference that both services can function. The major
differences between versions 1.1 and 1.2 are that 1.2 includes error detection and retransmission of trashed packets, an
improved protocol to discover partner devices, and better avoidance of subchannels with high interference, i.e. competing
protocols or microwave ovens.

There are two kinds of Bluetooth headsets. The ones designed for cellphones are monaural at 8000Hz, with a microphone,
with a mass of around 20 grams, designed to sit on or in your ear. They use the HSP and HFP profiles (see the list of profiles
later). The ones designed for music do stereo at 44100Hz (or sometimes 48000Hz) and have a mass around 100 grams, using
the A2DP and AVRCP profiles. Some music headsets also have a microphone and can switch to HSP/HFP for phone calls.

Also essential for the headset is a Bluetooth transceiver on the sound source. Some devices, e.g. some cellphones and music
players, have a builtin Bluetooth capability, but if your laptop or desktop computer does not have a factory-installed
transceiver you will need a USB or PCMCIA plugin device colloquially called a "dongle".

Equipment Chosen
After reading product reviews on the web I purchased these devices (from Amazon):

Motorola HT820 headset. Stereo audio over A2DP protocol and control of the player by AVRCP. It can also do phone
calls with HSP/HFP. Bluetooth 1.2 class 2 (10 meter nominal range). Mass 100 grams. Music time 12 hours or
standby 500 hours, on one battery charge.

Linksys USBBT100 Bluetooth Adapter. Bluetooth 1.1 class 2. That was a mistake. Lacking advanced competitor
avoidance and trashed packet retransmission, the Bluetooth 1.1 dongle frequently sends out packets that never arrive.
It sounds like popcorn in the sound stream, and can get bad enough to break the connection repeatedly. In forum
postings quite a number of users describe the same symptom in HSP (SCO) transmission to a telephony headset, with
various dongles. When I realized what the issue was, I replaced the dongle with . . .

Belkin F8T012-1 Bluetooth USB +edr Adaptor. Bluetooth 2.0 class 1 (100 meter nominal range). It's overkill to get
class 1 since the headphone is only class 2. This dongle worked well.

Dell type 355 (Broadcom BCM2045 chipset) internal Bluetooth transceiver, Bluetooth 2.0 class 2, factory installed in
my new laptop. This device also worked well.

Driver Availability
In theory, and apparently in practice, every Bluetooth device (headphone, etc.) interoperates with every other provided the
server offers the service (profile) that the client wants. In theory, USB Bluetooth transceivers (dongles) have little difference
when communicating with the host over USB (except see below). Every (?) Bluetooth dongle is sold with drivers for
/
Microsoft Windows, versions up to XP; the XP drivers, at least for the Linksys USBBT100, appear to work on Windows
Vista. There is a company called Widcom whose driver set seems popular among dongle vendors.

For Linux the BlueZ protocol stack supports Bluetooth. According to the documentation on that site the BlueZ software is
evolving rapidly and many of the HOWTOs are out of date; however you can review the documentation provided. The
kernel drivers support "virtually any" Bluetooth transceiver over USB or PCMCIA; occasionally types of Bluetooth
transceivers are reported on forums that are not handled by the standard drivers, but these are rare. The protocol stack itself
has been officially certified to interoperate with conforming client equipment.

Reasonably well-endowed Linux distros include Bluetooth support. This includes SuSE, Ubuntu and Debian, and likely
many others. Under SuSE (my distro) the package name is bluez-utils, which will bring in other dependent packages. I'm
going to assume that the reader knows how to install packages on his distro, and if he uses a custom kernel, how to turn on
Bluetooth drivers.

There are also the kdebluetooth and gnome-bluetooth packages. kdebluetooth is oriented to file transfer: OBEX (object
exchange) client, serial terminal, KDE tray applet, and a PDA sync application. gnome-bluetooth also has a OBEX client.
It's not clear what bluez-gnome does. None of these packages seems to have anything to do with audio, or with general
management of Bluetooth devices, i.e. initial pairing.

The daemon that handles the CD-quality audio link (A2DP profile) is called a2dpd, and a related daemon for telephony
(HSP/HFP profiles) is headsetd. (The btsco daemon and the snd_bt_sco kernel module are now deprecated.) a2dpd and
headsetd are not yet included among the standard set of profile daemons in Bluez, as of version 3.7; you need to get them
from CVS and compile them. Follow the instructions at http://bluetooth-alsa.sourceforge.net/build.html, which also includes
hints for configuring several popular players. Here are some "gotchas" connected with this package (which I downloaded on
2007-08-05):

A previous version of a2dpd downloaded around 2007-03-15 holds ALSA device hw:0,0 open for no obvious reason.
This prevents several of the players, and the sound proxies EsounD (esd) and PulseAudio, from starting. But the 2007-
08-05 version does not have this problem.

The instructions say to create ~/.asoundrc defining pcm.a2dpd, and if you're going to try out headsetd you also need
an analogous stanza for SCO. Here's what I set up:

# Bluetooth A2DP and SCO device

# A2DP is stereo output at 44100 Hz; SCO is mono input-output at 8000 Hz.
pcm.a2dpd {
type a2dpd
}
pcm.sco {
type sco
}

The default ALSA device is normally hw:0,0 (the 0'th subdevice on the 0'th physical sound card). To override the
default device, append to your ~/.asoundrc file a line saying just:

pcm.default pcm.a2dpd

Some players require an ALSA mixer to go with the PCM device, which would be named ctl.a2dpd or ctl.sco. This
facility was attempted in the 2007-03-15 version of plugz (my tests didn't get far enough to reveal if it actually
worked), but it was removed in the 2007-08-05 version. They suggest a "software volume" ALSA solution instead,
but I was not able to get it to do anything (yet).

In the absence of ctl.a2dpd, some players, specifically xmms, are able to substitute a "software volume control"
internal to the player.

There is a problem involving flow control, or the lack thereof in the A2DP profile definition. The symptom is that
some sound sources, particularly the sound proxies EsounD (esd) and PulseAudio, may send data too fast or too slow.
My experience is that this doesn't always happen, but when it does, you hear a kind of low frequency buzzing at 15 to
20 Hz, with loudness proportional to the music. My interpretation is that on each ALSA bufferload (not each
Bluetooth packet) there is a gap in the sound, possibly because the next batch is sent late. The a2dpd developers are
working on this issue and are planning a fairly major revision to cope with it, so be alert in the future when you
download the sources. Update: the 2007-09-19 CVS version does rate control, and the buzzing symptom has not
returned in about ten hours of testing.

Initial Setup
SuSE has a configuration tool called YaST that includes a Bluetooth module in the package yast-bluetooth (install it if
needed). Find its icon in the Hardware category. Other distros may have a similar configuration module, or you may be
editing files in /etc/bluetooth to accomplish the same effect.

Enable Bluetooth Services (mark the radiobutton).

Device Name: when your host announces its presence to other Bluetooth devices, this is the name used. It is an ASCII
string in which %h is replaced by the hostname and %d by the dongle's MAC address. Typically you use just %h for
the name.
/
 Security Manager: If your device never uses authentication, select "Use Local PIN" and fill in "0000". If it always
uses the same value (such as 0000), fill that in. It is written to /etc/bluetooth/pin. If your device generates its own
random PIN then you need to select "Always Ask User". (Note: the resulting configuration items are ignored by
hcitool, starting at or before version 3.7.)

Advanced Daemon Configuration: Here you can select what services your host offers to the outside world. At present
these include:

HCI: Basic Bluetooth device manager. Everyone needs this.

SDP: Service Discovery Profile. Everyone needs this.
RFCOMM: Serial datastream configuration. Basic infrastructure used by OPD, PAND, DUND and others.
OPD: Object Push Daemon. Needed to receive files from the remote device. The notes say that if you are using
KDE or Gnome you should let them use their own object push daemon, not to activate this one.
PAND: Ethernet emulation daemon. Needed for local network communication (not including cellphones),
imitiating Wi-Fi or wired Ethernet.
DUND: Dialup Network Daemon. Needed to make a global Internet connection through a cellphone.
HID: Human Interface Daemon. Needed for a wireless keyboard, mouse, or game controller.
HID2HCI: Special HID configuration, rarely needed.

Security Options: The authentication and encryption checkboxes govern whether we require other devices (e.g. a
keyboard) to provide a PIN when connecting, and whether we will then use that PIN as part of a key to encrypt the
session. (In the current version 3.7 of bluez-utils, these are always on, cannot be turned off.) The Inquiry Scan option
must be checked if remote devices are going to detect the presence of this host, and Page Scan must be checked if they
will be able to connect to this host.

Class Configuration: This host sends the Device Class to remote devices, describing what kind of computer (laptop,
etc.) this host is. The Service Classes list what this host can do for the remote device (not what this host hopes the
remote device will do for it). For example, you would mark "Audio" if you wanted a music player to be able to play
the music on your computer's speakers, whereas if you have sound files on your computer and want to play them on
headphones, the phones should advertise the "Audio" service.

The resulting /etc/bluetooth//hcid.conf came out as:

# hcid options
options {
autoinit yes;
# Security Manager mode - get passkey from dbus or pin_helper pgm
security auto;

# Pairing mode - multi = allow re-pairing even if already paired.

pairing multi;
}

# Default settings for HCI devices (dongles)

device {
# Name that we advertise to others. %h = hostname, %d = device ID
name "%h";

# What we claim to be able to do. 010c = laptop, 0104 = desktop,

# 0108 = server. Leftmost 10 = OBEX; "or" with 02 for networking,
# etc. See "man hcid.conf" for more codes.
class 0x10010c;

# Allow others to detect our presence [enable or disable]

iscan enable;
# Allow others to attempt to connect.
pscan enable;

# Default link mode (role): accept either role

lm accept;

# Default link policy, which modes to allow

lp rswitch,hold,sniff,park;
}

Hardware Initialization
When you insert the dongle, Hotplug will recognize the new USB device, load the needed drivers (for me, bluetooth,
hci_usb, l2cap, hidp), and start daemons (hcid, sdpd, hidd) by executing /etc/init.d/bluetooth. This mode is appropriate in the
common case that there is only one Host Controller Interface (dongle) which is plugged in after boot-up, but if the HCI is
internal or is plugged in before booting, or in the unlikely case of multiple HCIs, the script will attempt to start daemons
before /usr is mounted (if it's in a separate partition), or it may start a daemon more than once when it should be unique. The
set of drivers and daemons vary according to what you have configured your Bluetooth system to do. To check that the
dongle is alive, do hcitool dev and it should report a line with hci0 and the dongle's MAC address.

In the current version 3.7, the audio daemon a2dpd is not included. See the previous section on drivers for how to get it.
Normally the individual user starts a2dpd, described below.
/
Pairing With the Device
Before Bluetooth partners can communicate, they must go through a procedure called "pairing", by which the human owner
authorizes them to communicate, and by which the client device proves its identity to the master by means of a passkey. The
encryption key created during pairing is saved by both partners so they can connect later without re-doing the pairing. But
while bluez-utils can be paired with multiple partners at once, devices generally have storage for only one pairing, so if you
pair and use the device with a different machine and then come back to the first one, you will need to pair again.

The procedure is slightly arcane, and help requests in forums often turn out to be caused by errors in the procedure. Do these
steps in order.

hcitool dev -- Check that your Bluetooth protocol stack is running and that the dongle is working. It should show the
interface ID, typically hci0, and its MAC address, which you may or may not need later.

Put the device in pairing mode. For the HT820 you hold down the button (the Motorola logo) on the left speaker,
ignoring the flashes and beep saying it has powered on, until the light comes on steady. Consult the user's manual for
other devices such as a cellphone, wireless keyboard or mouse. Generally if pairing is not finished within a certain
time, the device will give up. If this happens, put it in pairing mode again and restart from this step.

hcitool scan -- It should report the MAC address and the description of the device that is trying to pair. Sometimes it
detects irrelevant devices such as neighbors' cellphones; ignore those.

passkey-agent 0000 11:22:33:44:55:66 & -- Make the passkey available to hcitool over the system dbus. Run the
agent in the background so you can do the subsequent step. Fill in the MAC address of the device you are pairing
with, and the passkey, which you get from these sources:

For generic low-security devices including the HT820, the default passkey is 0000.
If the device lacks a keypad, the device generally will take the master role and there may be a sticker on the
device showing the passkey that it expects the client to provide. Or the passkey may be disclosed in the user's
manual.
A wireless keyboard typically takes the client role. You make up a passkey and post it in the passkey-agent, and
in the next step you type the same passkey on the keyboard, so your computer knows authoritatively that it has
paired with the correct keyboard and not an irrelevant or possibly hostile competitor.
A cellphone doing dialup networking or object pushing typically takes the master role. When you put it in
pairing mode it may generate and display a passkey by itself, or may expect you to make one up on the keypad.
You then provide the same passkey to the passkey-agent, and it will be sent to the cellphone to prove that the
phone is talking to the correct client.

hcitool cc 11:22:33:44:55:66 (as root) -- "cc" means "create connection"; fill in the MAC address of the partner you
are creating the connection with. In this step the client and master create an encrypted connection, and the client sends
the passkey to prove its identity. The man page implies that in some configurations you need to give an argument
(after cc) of --role=s, allowing your machine to switch roles; the default of m means it always acts as the master
(which can be a problem if the other device also insists on being master). This behavior is specified in [my] hcid.conf,
and I can make connections without the switch.

hcitool auth 11:22:33:44:55:66 -- Forum postings suggest that in some configurations or with some devices, you
need to then do this command, which will create the link encryption key. However, for me this step is always included
in hcitool cc; hcitool auth does not attempt to read the passkey, sends no dbus messages, and does not modify
/var/lib/bluetooth/$MAC/linkkeys.

Now your device is paired. The HT820 automatically makes a connection, or some devices may have to be power
cycled to get them to connect.

Using the Device

The HT820 communicates using either the A2DP or HSP profiles, and the daemons for both of these are not a standard part
of the BlueZ package. See the previous section on drivers for how to get them.

The documentation suggests that the a2dpd daemon not be run as root, and since it has quite a bit of user-specific
configuration, particularly the MAC address of the headphone, it's best for the user to run it in his startup files, e.g.
.xsession. If you start a2dpd with no Bluetooth device, i.e. with hcid not running, it gets a segfault, so if you use the same
.xsession on several machines you should use hcitool to detect if any Bluetooth host interface (HCI) is present.

You can configure a2dpd partly with command line switches and partly in a file .a2dprc in your home directory. The file
begins with "[a2dpd]". # marks comments, and empty lines are ignored. You can find a commented sample file in the
sources: bluetooth-alsa/plugz/alsa-plugins/a2dpd/sample.a2dprc Here are the command line switches and .a2dprc
equivalents where relevant:

Switch .a2dprc Description

-n Do not fork (default)
-d Do fork, run as daemon (you want this)
-k Kill running daemon
/
-g enabledebug=1 debug output
-v Write chatter on stdout (vs. no chatter)
-l file logfile=filename Verbose chatter to this file
-r Set realtime priority (you want this if permissions are set up)
-a MAC address=MAC Connect to this MAC address
-o enableautoconnect=1 Auto connect to headset (recommended, but messes up on Bluetooth 1.1)
rate=44100 Samples per sec; some headsets want 32000 or 48000; 8000 is correct for
HSP (telephony)
sbcbitpool=32 Compression quality; higher is better, but takes more bluetooth
bandwidth. HS820 can go up to 33; Bluetooth 1.2 can do up to 53; max is
64.
enablereversestereo=1 Not sure what it does, but it's recommended
timeout=20 Disconnect if unused for so many seconds (older version used units of 3
msec)
enableavrcp=1 Enable AVRCP player controls
cmdplay etc. AVRCP player command lines (see below)

If you turn on the headphone and then start a2dpd, then when an audio source attaches to a2dpd and starts playing, a2dpd
will initiate a connection to the headphone, provided you have -o on the commandline or enableautoconnect=1 in .a2dpd.
This works (if it's paired). I recommend using this switch. Remember that the MAC address of the headset must be specified
explicitly.

If you start a2dpd and then turn on the headphone, the headphone will attempt once to connect to its paired partner. a2dpd
will then launch the player specified in cmdplay (with no file) in .a2dprc. This works (if it's paired and if the player is
configured to talk to a2dpd).

If you have enabled AVRCP (Audio-Visual Recorder Control Profile), then when the headset sends an AVRCP packet,
a2dpd will execute the corresponding command line, using execve, not a subshell. Here is a sample configuration using
xmms; you can rewrite it to use your favorite player, such as Amarok. But beware when testing: A2DP involves buffering
various places, and the sound will continue for 5 to 10 seconds after you press the buttons to pause or skip tracks.

.a2dprc HT820 Action Description

cmdplay=xmms --play Turn on phones When initiating a connection
cmdpause=xmms --pause Right logo button Temporarily stop music
cmdnew=xmms --play Right logo button again Restart after pause
cmdprev=xmms --rew Right top rear button Previous track (or restart current one)
cmdnext=xmms --fwd Right top front button Skip to next track
cmdstop=xmms --stop Right logo button (hold down) Halt playback

Torture tests:

The laptop acts as an audio gateway: it brings in content from a media server via 802.11b and sends it out via
Bluetooth. The two services appear to coexist fairly peacefully. The noise level reported by 802.11b is clearly higher
and more variable when Bluetooth is communicating, but ping to the same host showed no lost packets. I'm sure
packets really were trashed, but evidently the lost packet retransmission feature was effective on both Bluetooth and
802.11b.

While listening as above, I started a process to copy a very large file from the server to the laptop using 802.11b. I
only heard one very short dropout, and again, ping showed no lost packets.

I was able to get good reception with only occasional unrecovered packets at a distance of 11 meters, line of sight (no
walls). Beyond that, the dropout rate rose a lot and the connection would have been lost had I not returned promptly
within range. Except for competition from 802.11b these were ideal conditions. The nominal range of a class 2
Bluetooth device (the headphones) is 10 meters. I have the impression that at least with Bluetooth v1.2 the receivers
occasionally report the received signal strength back to the transmitter, and at short range the transmitters use reduced
power, and increase it to the max (10 milliwatts, not much, for class 2) at long range.

Gather round the microwave oven, right next to the 2.4 GHz cordless phone's base station, and nuke some tea. This
trashed so many packets that the player had repeated underruns: retransmissions were taking up a lot of bandwidth and
it was unable to send out the payload on time. 802.11b showed a major reduction of signal at the same time. Isolating
the two competitors: the oven had the largest effect, and a second oven was similar. Not sure about the phone.

Audio Players: Catch-22, Catch-31, etc.

Configuring EsounD (esd) Daemon

The 2007-03-15 version of a2dpd held open the ALSA device hw:0,0, and the mixer device was broken (implemented by
the shared library /usr/local/lib/alsa-lib/libasound_module_ctl_a2dpd.so). One or the other of these two problems prevented
most players from working, and I ended up using xmms through the Enlightenment Sound Daemon (esound package, /
ftp://ftp.gnome.org/pub/gnome/sources/esound/). The 2007-08-05 version leaves hw:0,0 alone, so you don't need to use a
sound proxy if you don't want to. To configure EsounD:

First ensure that ~/.a2dprc includes the AVRCP command lines described above, so the player can be properly launched on
initial connection and so AVRCP commands can be sent to the player. If you're using a different player, adjust the command
line arguments as needed.

Edit /etc/esd.conf, and to the spawn_options add "-d a2dpd" to make it use the A2DP (Bluetooth) sound device.

Start EsoundD (/usr/bin/esd). You may do this before or after you start a2dpd but it should be running before the player
starts. (But some players like xmms can spawn it automatically, once per track.) If you're using the Gnome desktop, esd
would presumably start when you log in and stop when you log out. The command line I use is:
esd -nobeeps -r 44100 -bind 127.0.0.1 -d a2dpd

-nobeeps: When starting, the daemon plays a "splash sound" which is loud and annoying. All documentation examples
include -nobeeps to suppress it.
-r 44100: Sample rate in Hz, matching the CD-quality sound which I'll most often be using. Either xmms or EsoundD
(can't tell which one is doing the work) is able to resample a 32000 Hz MP3 stream to the specified rate.
-bind 127.0.0.1: To avoid having to think about security from outside hackers, restrict only to the localhost address.
-d a2dpd: ALSA output device name. "esd --help" reports only hw:0 as a possibility, but it's not imaginative enough.

How to configure xmms to use EsoundD: Ctrl-P in the player window opens the preferences dialog. Select the "Audio I/O
Plugins" tab. In the "Output Plugin" section select the "eSound Output Plugin" (libesdout.so). If you have not started esd
yourself already, this library will start it automatically when needed, once per track. It is sufficient to leave the plugin
configuration items at their defaults.

You will also want to configure your web browser to use xmms or your preferred player to play sound files. xmms can
accept the URL of a remote sound file (ogg or mp3), but for a m3u playlist, as for streaming audio, the browser needs to
download the file and give the browser cache copy to xmms. Some but not all other players can download a m3u URL for
themselves.

To play sounds you will need the Bluetooth dongle plugged in, hcid running, a2dpd running, and the headphones turned on
and paired, plus the above items. With these settings the sound system on the laptop appears to be fully operational over
Bluetooth except for the minor detail of flow control, described previously.

The one problem with EsounD is that when you want to change the output device, e.g. between wired and Bluetooth
headphones, you need to edit /etc/esd.conf and restart the daemon. An alternate sound proxy is PulseAudio. It is designed to
be a drop-in replacement for EsounD, but you can reconfigure it on the fly, e.g. VOIP uses the Bluetooth phones while the
music player goes to speakers, but you can put both on speakers, or both on phones, easily using a GUI. But sound proxies
are off topic, and I'll post my experiences with PulseAudio on a separate page.

Video Poison for Xine

What does video have to do with audio players? First, many of them have a visualization feature, displaying a sound
spectrum or creating an artistic representation of the sound. Second, many of them also can play video, and they always
initialize both the audio and video portions of the engine. Which then proceeds to crash.

I have an ATI Radeon Mobility X1400 graphics card in my laptop, and I am using the fglrx (FireGL) proprietary driver from
ATI, to make 3D rendering (DRI) function. It turns out that the implementation of the XVideo extension is less than perfect
and is poisonous for at least the Xine multimedia engine. According to web postings, quite a number of users have crashes
in Xine related to XVideo on a variety of hardware such as nVidia, Intel 950 and SiS onboard video, in addition to ATI.
According to the xine-bugreport script the cure is to use player-specific switches or configuration to make it use a video
driver other than xv (XVideo). They recommend xshm as being the most likely to work, though it's CPU intensive. I found
that the opengl driver also worked with the Radeon, and that's what I've been using.

If the player crashes before opening its GUI, the generic method to get it under control is to do "player --help" to discover
the command line switch to force a particular video driver. Use that to survive initialization. Then in the preferences or
settings dialog, permanently configure the working video driver; after that you won't need the command line switch.

Configuring GStreamer

Several of the players use the GStreamer engine, which is a framework for connecting players to audio and video output or
input libraries. Generally the players have limited ability to configure GStreamer, if any. The "correct" way to configure it is
to use the program gstreamer-properties. On its GUI you will find tabs for audio and video.

Audio

You want ALSA output; the pipeline is just "alsasink". If you hit "Test" it will play a sine wave. This plugin will play
on the default ALSA device. If you have not configured the default to be a2dpd, you can override that here. Select the
"Custom" output pipeline, and edit it to say alsasink device=a2dpd.

There are also sinks for various sound proxies, including EsounD (esd), aRTSd (for KDE), and PulseAudio; in my
distro the latter has to be built from source. /
 According to this web posting, if you can't use gstreamer-properties, the manual incantation to make gstreamer use a
particular output device is:

gconftool -t string --set /system/gstreamer/0.10/default/musicaudiosink 'alsasink device=a2dpd'

(I have gconf2-2.14.0 and the command is gconftool-2 in this package.)

Video

Although the Xine engine dies with the default video driver, both GStreamer drivers worked for me. Ximagesink takes
12% of one CPU consistently, whereas Xvimagesink (using XShm and XVideo) seems to take about 0.4%, so that's
the one I use. Use the "Test" button to check on your machine, and to test other drivers that may be in your distro.

Controlling the Player by AVRCP

AVRCP works. On the Motorola HT820, the music controls are on the right speaker. To pause or resume music, press the
big center button briefly. To stop (forgetting the current track position), hold it down for a second or two. To skip to the
previous or next track, briefly press the similarly labelled button on top of the speaker; but due to buffering various places in
the data chain it will take 5 to 10 seconds for the transition to happen.

The volume control is on the left speaker. It appears to affect what the headphone does with the signal it's given, rather than
affecting the data source. The left buttons are mainly for HSP-HFP (voice phone) operation.

Rogue's Gallery of Players

Initially I could not get xmms to play on a2dpd. (My problems were rectified later.) I searched on Google for other
possibilities, and found just this one review of audio players by Peter Enseleit dated 2006-04-04. It was clear that his
installation lacked a number of plugins needed for the file formats he wanted, but the review gave me some ideas of
alternative media players to try. Here are my results. I did make sure I had the plugins I needed, or at least I attempted to
find them.

Initially almost all the players failed for me, and my main interest in this section was to identify any players that could
perform on the Bluetooth headphones. But it turned out that I had generic problems with both the Xine and GStreamer
engines, and once these were tracked down and fixed, all the players revealed their true personalities. So I've turned this
section into a brief player review. The reader should understand where I'm coming from:

I'm a lot more interested in audio than in video. In my limited experience with streaming video it seems that the
content providers give you captive streams to be played on proprietary web browser plugins, which makes it hard to
use these streams to test players. Apparently I have not successfully found and/or configured the codecs to play H.263
and H.264 encoded videos, despite compiling several libraries and plugins from outside the USA. I did, however, spot
one useful test: Lennart Pottering's PulseAudio talk at linux.conf.au 2007 in Sydney. This is encoded with Theora, and
I have this codec, so that's what I downloaded (90 Mbytes) for testing.

Your typical media-savvy teenager has on his computer a large collection of tracks from dubious sources, and some of
the players can index and organize this music similar to Apple's iTunes. I store my legally owned tracks on a media
server which streams them out to whichever of my machines I'm using, and indexing is done (on the server) by my
own scripts. Thus I'm not evaluating how good the player's indexing ability is, just noting whether it's present.

A few of the players have tie-ins to a commercial music source. I did not turn these on, just noting their presence.

All my music is ripped to Ogg Vorbis format, which all the players support, and MP3 is the format preferred by most
media addicts, also supported. These are not the only formats supported, but as breadth of format support is off topic
in a Bluetooth howto, I did not systematically evaluate this aspect.

Here is a generic summary of the results. (The term MRL means "Media Resource Locator", essentially a URL or a
filename.)

Audio Most play local or remote MRLs; a few do local files only.
Video Either no video, or same MRL types as audio.
Playlists Most accept m3u playlists, but have their own native format. Only a few can bring in a playlist
from a remote host.
To play $program $MRL (mostly). Most but not all can pass the MRL to a running instance. Many but not
all can take a playlist on the command line.
Media indexing Sometimes
Purchase media A few have commercial tie-ins.

The players tested are listed here in order of preference, using my idiosyncratic criteria.

xmms-1.2.10

This player is deprecated (vocally) by the Gnome developers because it uses the obsolete GTK-1 widget library rather
than GTK-2, but it works and it has plugins for the inputs and outputs I want, so this is the one I normally use. Also I
/
 like the half-size control window, which is useable but doesn't waste a lot of space on the screen. To configure it:

Execute "xmms < /dev/null". If you put it in the background, some unknown component, clearly involving
ALSA communication to a2dpd, reads stdin, and it hangs if stdin comes from the terminal. If the web browser
or a2dpd itself spawn xmms, they will redirect stdin by themselves.
Use control-P to open the preferences dialog.
Turn to the Audio I/O Plugins tab if not open already.
Under Output Plugin (the bottom section), in the dropdown box pick "ALSA Output Plugin". (Or EsounD or
PulseAudio.)
Hit "Configure"; set the audio device to "a2dpd", and select Software Volume Control (since there's no mixer).
(For EsounD take the defaults in configuration; note the port number of 16001. PulseAudio has no
configuration settings.)

Audio Plays local or remote MRLs

Video None, refuses test file.
Playlists m3u file, local only
To play xmms --play $MRL (--play is optional)
Media indexing None
Purchase media None

xine-0.99.4 (engine 1.1.2)

This is the official player that comes with the Xine engine. It gives you no nonsense; it either plays the file or it
doesn't, without a lot of messing around with indexing features.

For some reason the control window was not shown upon startup; Right click in either the playback or control
window to show the main menu, and there is a checkbox to turn on the control window.
The main menu also has an item for "Settings", and under that, "Setup". There is also a button on the control
window for this, decorated with a squiggle; it's obvious which one it is.

Audio Plays local or remote MRLs

Video Yes, plays test file
Playlists Has a special format (TOX extension). M3u files are accepted (use -P on command line).
To play xine $MRL (a separate instance plays; it does not pass the MRL to an existing instance.)
Media indexing No
Purchase media No

totem-2.17.0

Totem is a video player intended for Gnome, using the GStreamer engine. It seems easy to use in this context.

Execute "totem".
Under "Edit/Preferences", there were no useful settings for choosing the audio device. See here for the "right"
way to configure GStreamer.
When I had GStreamer mis-installed, Totem was the only player to give me a useful error message announcing
which plugin was missing.
When I added to the playlist a local file or a URL (ogg), Totem played it. However, it starts with the volume at
zero (unlike the other players) and you need to turn it up to hear the sound.

Audio Plays local or remote MRLs

Video Yes, plays test file
Playlists Native format is special; m3u files and URLs are accepted.
To play totem $MRL
Media indexing Yes
Purchase media No

amarok-1.4.4

This is a full featured audio player, intended for KDE, which has a separate control window and playlist and music
management window. (Turn on the control window in "Settings".) In my distro, OpenSuSE 10.2, it uses the Xine
engine; in the previous version it also could use the Helix engine that comes with or is related to RealPlayer, and I
believe there is a gstreamer engine for Amarok but it's not in my distro. For me, the KDE entanglements are a
disadvantage because I don't have any of the needed infrastructure running. Configuring it was simple:

In the "Settings" menu, "Configure Amarok".

Select "Engine".
Under "Sound System", pick Xine (for me it's the only choice).
For "Output Plugin", pick ALSA.
/
 For "ALSA Device Configuration", it starts out as "default"; you can change to "a2dpd" if you have not set that
up as the default device.

I had a lot of trouble with Amarok because I had configuration files left over from the previous version, which for
some reason caused it to crash. But once I removed them it started right up. The files were
~/.kde/share/config/amarokrc and ~/.kde/share/apps/amarok (directory). Likely if I used Amarok regularly my music
collection would have been indexed here, and if this is your situation you should remove files selectively.

Audio Plays local or remote MRLs

Video No video, but plays audio portion
Playlists M3u files, local or remote
To play amarok $MRL (music or playlist)
Media indexing Yes
Purchase media Magnatune

kaffeine-0.8.2

This is mainly a video player, but it could play audio on a2dpd. It's a KDE program, like AmaroK. My setup is neither
KDE nor Gnome, and Kaffeine needs to start an enormous amount of KDE infrastructure, and even so finds a lot of
errors due to missing pieces.

Execute "kaffeine".
Under "Settings", select your sound engine: Xine or GStreamer.
Under "Settings/(name of engine) Parameters" set these up:

Xine
Under "audio", for the driver pick "alsa" ("auto" got this right, though). Mark the checkbox for software
audio mixer. If your Xine engine crashes, then under "video" pick a working driver such as xshm. Open a
MRL (a local or remote music file). It plays on the default ALSA device; see here for how to override
this.
GStreamer
Under "audio", select the alsasink driver. (Or esdsink; I don't have the PulseAudio sink, though one
exists.) See here for the right way to configure GStreamer. Open a MRL and it will play.

Audio Plays local or remote MRLs

Video Yes (both Xine and GStreamer)
Playlists Native format is XMLPlaylist; m3u is accepted. Remote playlists are copied to a cache, then
obeyed.
To play kaffeine $MRL
Media indexing Yes
Purchase media None

rhythmbox-0.9.6

This is intended for Gnome and uses the GStreamer engine. Apparently its main use is to organize and play files
stored on the local machine, like iTunes. Remote URLs are handled separately, as if they were "Internet radios".

Execute "rhythmbox".
Under "Edit/Preferences", there were no useful settings for choosing the audio device. See here for the right
way to configure GStreamer.
Eventually I was able to figure out how to add a file to the play queue. That done, it could be played on the
Bluetooth phones.
When previously there is a problem with GStreamer, the error message was visible for only 50 msec and I
couldn't read it, leading me to give up on Rhythmbox, until I got GStreamer fixed in a different player.

Audio Plays local or remote MRLs

Video None; it ignored the Theora test file
Playlists Special format, m3u not accepted.
To play rhythmbox $MRL
Media indexing Yes
Purchase media No

banshee-0.11.2

My distro (OpenSuSE 10.2) includes Helix-Banshee, which appears to be entangled with Real Networks, Inc. The
Helix engine is software belonging to Real Networks. On installation it requires you to accept an EULA with
extensive DRM and DMCA clauses and delivery of personally identifiable information to Real Networks servers "to
access your account". There is also a GStreamer engine installed, but Helix is the default and I could not find how to
/
 switch to GStreamer. There were also limited means to configure Helix, but it seemed to work. If you run it in the
background, you need to redirect stdin, stdout and stderr to /dev/null or it will hang.

Audio Plays local or remote

Video No, but auto-switched to GStreamer and played the audio portion
Playlists It does not accept m3u files. I couldn't figure out how to add music and save a playlist, to find
out what the native format was.
To play banshee $MRL
Media indexing Yes
Purchase media While the EULA mentions Real Media servers, I was not able to identify them.

xfmedia-0.9.2

This is a very lightweight player without glitzy skins or media management features. It is part of the xfce4 desktop
suite, which I am in the process of adopting. It uses the Xine input/output engine, and GTK-2 for the user interface.
This particular version is definitely beta quality: it can play local files, but dies when given a URL of an audio file,
which is why it's not higher on my list. The developers are aware that this aspect is not finished.

The Xine ALSA driver is going to play on the default ALSA device, and (at least in this version of xfmedia)
there's no way to configure it differently, nor (as far as I can find) an environment variable for that purpose. See
here for how to override the default device.
In xfmedia, the Xine engine defaults to using the xv (XVideo extension) video output driver and EsounD (esd)
audio output. If your Xine engine crashes on startup, execute "xfmedia --video-out=xshm --audio-out=alsa" to
use a working video driver.
Right click in the GUI's background, and find "Preferences" in the resulting menu.
On the "Devices" tab, change the audio and video drivers from "auto" to alsa and xshm (or whatever works for
you). Subsequently you won't have to override these settings on the command line.
You can open a M3U playlist, or you can create a new one. To add files, hit the plus sign on the GUI and give
the filename, or a directory of sound files, in the resulting dialog box.

Audio Plays local files; remote is not finished yet.

Video Supposed to, but for me it just hung.
Playlists m3u file. Not sure if remote m3u will be supported. You can't put a playlist on the command
line and have it played.
To play xfmedia $MRL (note, does not coordinate with a running player, opens a new instance)
Media indexing None
Purchase media None

MPlayer-1.0

This is mainly a video player. I was able to test this in SuSE 10.1 and it played streaming MP3 on a2dpd, but froze
when given other formats. Evidently it's been dropped from SuSE 10.2, and I'm not willing to build it from source just
to try it again. This glowing review of SuSE 10.2 includes a link to a list of third party sites that have RPMs of
MPlayer components.

Comparing Wired with Wireless

I'm not totally happy with the sound quality of the Motorola HT820. Is the problem with the phones, or with the codec on
Bluetooth? The test procedure went like this:

Pick music. Chopin's solo piano music gives a good broad spectrum signal. Specifically, the Polonaise in A, opus 40
no. 1 "Military", performed by Artur Rubenstein; RCA Victor 7725-2-RG.
For best results, I'm playing it off the CD; however, an Ogg Vorbis or MP3 file at 128 kbits/sec should be enough to
reveal any problems.
Get Bluetooth headphones running. Memorize the sound.
Reconfigure the player or sound proxy to play on wired headphones, typically ALSA device hw:0,0.
Turn off the HT820 and plug in the provided cable for non-Bluetooth operation.
Play the track again.

Evaluation: The sound over Bluetooth was noticeably less good than the same headphones with wires. Both bass and treble
were reduced. I blame this on the SBC codec, which is rather simple, not on any issues specific to the Motorola HT820
phones. If they would use Ogg Vorbis or MP3 as the codec -- SBC is required but other codecs are allowed on an optional
basis -- then they could get much better sound over limited bandwidth, but the phones would have to support it, and they
don't, and won't, being closed-source.

Comparing the wired HT820 with a Kenwood KPM-410 "around the ear" headphone (audiophiles please don't laugh too
loud; this is not a studio-quality headphone), the Kenwood's bass was significantly better, probably because the "on the ear"
design of the HT820 lets the bass leak out. On the other hand, with the wireless headphones you're able to move around
freely, a big advantage.

/
Also, the flow control problem described previously makes Bluetooth sound unreliable over a sound proxy, at least until the
issue is dealt with in the coming major revision. (Fixed as of 2007-09-19.)

So in conclusion, there are advantages and disadvantages to using Bluetooth (A2DP) stereo headphones, specifically the
Motorola HT820. You'll get freedom of movement, but you'll give up sound quality and be exposed to interference. Each
individual user will have to decide which aspect is more important. If you do decide to go with Bluetooth, the Motorola
HT820 is a decent headphone to choose (if you boost the bass).

Bluetooth Profiles
Here is a list of Bluetooth profiles from the bluetooth.com website, complete as of 2007-03-29 (organized and summarized
by jimc).

Audio-Video
A2DP Advanced Audio Distribution Profile. High quality stereo audio.
VDP Video Distribution Profile. H.263 video streaming. (Watch for H.264 support which uses half the
bandwidth.)
AVRCP Audio-Visual Receiver Control Profile. Controls audio-video devices (play, stop, next track, etc.)
HSP Headset Profile. Audio 8000 Hz mono + microphone. AT command set to dial a phone.
Telephony
HFP Hands Free Profile, for making phone calls. Builds on HSP and adds call control (accept call,
hang up, etc.)
CTP Cordless Telephony Profile. Talks to base station with landline.
ICP Intercom Profile. 2-way audio between devices in the same net.
FAX ITU T.31 or T.32 command sets for sending a FAX.
Data Transfer
BIP Basic Imaging Profile. To transfer images with another device.
BPP Basic Printing Profile. (Compare to HCRP)
FTP File Transfer Profile. Client browses server files. Uses GOEP and OBEX.
OPP Object Push. Defines objects like vCard, sends by OBEX, GOEP.
SYNC Synchronization. Syncing PDAs. Uses GOEP.
WAP Wireless Application Protocol for phone web browsers.
Networking
DUN Dialup Networking. Uses SPP; uses AT modem command set to dial.
PAN Personal Area Network. Establishing a net for BNEP transport.
CIP Common ISDN Access Profile.
Other Application-Layer Profiles
HID Human Interface Device (keyboard, mouse, joystick, game controller). Imitates USB HID.
SAP SIM Access Profile. One device (e.g. phone) can use the SIM in another.
HCRP Hardcopy Replacement Profile. for printing; no command set specified. See also BPP.
Streaming and Networking Infrastructure
AVDTP Infrastructure to define audio-video stream for A2DP, VDP.
AVCTP Infrastructure for AVRCP
GAVDP General Audio/Video Distribution Profile, for A2DP and VDP.
BNEP Basic Network: 802.3 (Ethernet) encapsulation for PAN.
Generic Streaming Infrastructure
SPP Serial Port Profile. Setup for RFCOMM. Used by DUN, FAX, HSP, LAN.
RFCOMM Serial cable imitation. Foundation of many other profiles.
Other Infrastructure
GOEP Generic Object Exchange Profile. Uses SPP. Used by OBEX.
OBEX Object Exchange. Same as IrDA OBEX. Used by FTP, OPP, SYNC.
TCS/TCP Telephony Control. ITU-T Q.991, to establish voice or data calls.
Lowest Level Infrastructure
SDAP Service Discovery Application Profile. Application and user interface for SDP.
ESDP Extended Service Discovery Profile, transports Universal Plug and Play.
SDP Service Discovery Profile. Discovers partners' services.
GAP Generic Access Profile. Discovery, establishment, basic UI. Foundation of all the others.

Bluetooth class 1 devices have a nominal range of 100 meters; class 2 is 10 meters; class 3 is 2 meters or so. The listed range
is rarely achieved in real life due to absorbtion by walls and interference by other devices.