Valid HTML 4.01 Transitional

Bluetooth Bluez

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



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

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, which also includes hints for configuring several popular players. Here are some gotchas connected with this package (which I downloaded on 2007-08-05):

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.

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.

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:

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/ 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, 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 -d a2dpd

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


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

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:

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.


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:

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.

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 is a video player intended for Gnome, using the GStreamer engine. It seems easy to use in this context.

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

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:

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

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.

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

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.

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

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.

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.

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

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:

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 website, complete as of 2007-03-29 (organized and summarized by jimc).

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