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:

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.

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

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

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.