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.

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 . . .

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:

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.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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:

(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.

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.

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.

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.

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.

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.

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.

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 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.