Brighten Up Your Bluetooth Designs With High-Quality Audio

With over 100 million Bluetooth-enabled products shipping in 2004 and predictions of over 200 million for 2005, Bluetooth (BT) has well and truly arrived. Questions of "Will there be devices to connect with?" have been replaced by "How well will my device interoperate with your device?"

Until recently, BT audio transmission was fairly straightforward. The BT specification only defined one mechanism, and there were few options to complicate matters. Now, the release of the BT 1.2 specification and a new high-quality audio profile has complicated this once simple feature. Because streaming data is the basis of all digital audio transmissions, the available methods differ in transport mechanism, encoding method, data rate, packet length, and error detection/recovery.

Bluetooth is a packet-based, frequency-hopping protocol using a time slot of 625-ms duration. In each pair of communicating BT devices, one is the connection master, and the other is the slave. Generally, a slave device may transmit data to the master in the slot following receipt of a packet from the master. Bluetooth defines two basic mechanisms for audio-data transmission.

The original BT audio transport mechanism is the synchronous-connection-oriented (SCO) channel, which supplies full-duplex data with a 64-kbit/s rate in each direction. In the absence of RF interference, SCO audio quality is similar to that of a typical cellular phone. This is to be expected since Bluetooth was developed with phone-headset applications in mind. SCO data is transmitted in dedicated time slots, which guarantees bandwidth and a fixed arrival time for the packets.

Bluetooth transmits nonsynchronous data using the Logical Link Control and Adaptation Protocol (L2CAP). L2CAP multiplexes all nonsynchronous transmissions over available BT bandwidth. These include serial data (for example, AT commands and responses), service discovery data, and isochronous data used to support streaming audio and video channels. Figure 1 shows a protocol layer diagram.

The introduction of the Bluetooth 1.2 specification, which enhanced Bluetooth's quality-of-service (QoS) features, greatly improved the utility of isochronous data. These improvements enable applications to request bandwidth and latency guarantees for their data streams.

Selecting The Right SCO Channel SCO channels offer little in the way of customizable features. The bit rate is fixed, and while three coder-decoders (codecs) are defined, only one-Continuously Variable Slope Delta (CVSD)-is used in practice. The other codecs (A-law and µ-law) offer better sound quality but don't tolerate data errors as well as CVSD. Since the SCO channel offers limited error detection/correction and no packet retransmission, CVSD is the safer choice.

SCO provides full-duplex audio. The connection master will send one packet of data to the slave, which will respond in the next time slot. The specific packet type used is typically left up to the link manager firmware in the BT chip set, though there is a way to select a specific type. Bluetooth defines four packet types for transmitting SCO data (see the table).

Whether selected by the chip set or the system designer, there are tradeoffs to consider when selecting an SCO packet type. HV1 packets, while producing better error recovery than other types, accomplish this by consuming the entire bandwidth of a Bluetooth 1.1 connection. HV3 packets supply no error detection, but they only consume two of every six slots. The device can then establish other connections while maintaining an SCO connection. This isn't possible when using the HV1 packet type for the SCO data. Figure 2 depicts an SCO timing chart.

Under optimal conditions, packet type won't affect audio quality. The data transmitted is exactly the same in all three cases. HV1 and HV2 packets allow for some bit-error correction. But typically, bit errors don't significantly degrade audio quality. Dropped packets are the most likely cause of poor audio quality.

A BT packet contains an access code, a header, and a payload. While a 1/3 forward-error-correction (FEC) code and an error-checking code protect the header, low signal strength or local interference may result in a packet arriving with an invalid header. In this case, the entire packet is discarded. Because there's no mechanism to request retransmission of an SCO packet, the data is simply lost.

If the link uses HV1 packets, less data is lost, so there will be less audio pop energy in one lost packet. If the packets are lost due to narrow-band or short-duration interference, HV1 may offer better audio quality than HV2 or HV3 packets. This isn't a certainty, as HV1 also transmits more packets and therefore has a higher potential for packet loss in a noisy environment.

The Bluetooth 1.2 specification adds capabilities that improve SCO audio in the face of local interference. A good example is IEEE-802.11b, which occupies a band of approximately 22 MHz in the ISM band, or 22 channels of the Bluetooth spectrum.

Bluetooth uses 79 channels, spaced at 1-MHz intervals. Adaptive Frequency Hopping (AFH), added in the 1.2 specification, allows a pair of BT devices to avoid channels that are known to be blocked. The two devices can develop a channel map in real time, or it can be supplied to the radio from upper-layer software. The latter model enables easier coexistence in devices that contain both Bluetooth and 802.11b nodes. The device software can supply the BT module with a new frequency map that prevents the use of channels in the range occupied by the 802.11b node. With fewer packets lost to interference, audio quality is improved. The hopping algorithm used by AFH can operate with as few as 20 good channels. The downside to AFH is that reducing the operational channels increases the probability of interference from nearby Bluetooth connections.

Extended SCO Channels Another addition to the Bluetooth 1.2 specification is the Extended SCO (eSCO) channel, which offers more flexibility in channel parameters and permits retransmission of bad packets. These extensions, combined with AFH, deliver better audio performance than the BT 1.1 standard SCO channel.

In the simplest case, an eSCO channel operates very much like an SCO channel, albeit with a new packet type. Audio data is broadcast in single-slot packets containing from one to 30 data bytes, but eSCO adds two enhancements. First, the packet contains a CRC code used to check the data's validity. (This is not present in the HV3 SCO packet.) Second, if an error is detected, the receiving device may be able to request retransmission of the faulty data. This depends on how the channel was configured, since frames must be reserved for possible retransmissions.

The downside to retransmitting packets is an increase in power consumption by both devices. Using AFH can minimize this effect. If packets are being lost due to a fixed-band interferer, such as 802.11b, AFH allows the BT devices to avoid the known bad channels, reducing the need to retransmit packets. Designers also need to consider data latency, since retransmitted data will arrive at least 1.2 ms after its scheduled arrival time.

As mentioned earlier, SCO channels use CVSD audio encoding due to the high potential for lost or damaged data. Other codecs provide better fidelity but behave badly when supplied with faulty data. Given the greater data integrity of eSCO, it should be possible to use the other codecs to improve sound quality without increasing the basic data rate of 64 kbits/s.

SCO data is symmetric, full-duplex, and fixed at 64 kbits/s. Using eSCO will add two multislot packet types and allow for asymmetric data rates. In fact, no data needs to be transmitted at all. If an eSCO channel is unidirectional, say for example an audio museum guide, the receiving device can acknowledge an incoming data packet with a very small return packet called a NULL. Depending on the negotiated parameters, data rates on an eSCO channel may be as high as 288 kbits/s using multislot packets, opening the possibility of supporting advanced codecs, including video transmission.

Ironically, it's the wealth of options in the eSCO inventory that causes the most difficulty in effectively using the feature. Channel options, such as data rate and codec, must be negotiated at the application level. The Bluetooth working groups responsible for profile specifications that utilize SCO connections are working to develop a strategy for integrating eSCO into their profiles.

One suggested approach is a phased introduction of the features. The first phase would limit eSCO to a 64-kbit/s, CVSD encoded channel. This is effectively the same as an SCO channel, which limits the demands on the supporting hardware and software. As experience is gained, more features will be introduced. If this seems overly cautious, keep in mind that one source claims that "with eSCO there are approximately 55 different configurations that achieve symmetric 64 kbits/s." The author has not tried to independently verify this calculation, but it clearly shows the potential complexity of negotiating eSCO parameters.

A specification for Wideband Speech is currently under development. The driving force behind this feature is the inclusion of a similar feature in 3G cellular-phone technology. Given the high volume of Bluetooth products targeting the cell-phone accessory market-headsets, hands-free car kits-it's necessary that the audio quality of a phone-to-accessory link should be at least as good as the quality of the audio coming into the phone from the cellular network. The details of Bluetooth wideband speech are still being hammered out, but it's clear that eSCO will be used as the transport mechanism.

Advanced Audio Distribution Profile As its name implies, the recently adopted Advanced Audio Distribution Profile (A2DP) is designed for the distribution of high-quality audio data. The unidirectional audio streams may use any desired codec. Yet to achieve guaranteed interoperability, A2DP specifies one mandatory codec. Streams may contain a single audio channel, or joint stereo encoding, as determined by the source data and codec.

As mentioned earlier, BT provides transport services for synchronous and non-synchronous data. A2DP uses an isochronous data channel carried by the L2CAP layer. Between A2DP and L2CAP is the Audio/Video Distribution Transport Protocol (AVDTP). This protocol layer defines the transport mechanisms for streaming audio and video (Fig. 1, again).

A2DP and AVDTP define the encoding, transport, and decoding of the data stream. An additional profile is available to control the content of the streams. The Audio/Video Remote Control Profile defines the basic elements required to implement a remote control device.

Utilizing a combination of these elements, users might bring Bluetooth-enabled digital audio players into their vehicles and take advantage of the vehicle's built-in sound system to control the player as well as listen to its content. Bluetooth has sufficient bandwidth to support high-quality, stereo-encoded audio streams, offering users high-quality audio reproduction with no cables required. Given the rapid consolidation of features, or gizmo accretion, into electronic assistant devices, the audio source could well be a cellular phone or PDA. A2DP is already seeing use in wireless stereo headphones and remote, powered speakers for home audio systems.

Consider The Application As we have seen, Bluetooth offers an array of choices for transmitting audio data. Selecting a particular method should start with the application. If the application is based on a standard Bluetooth profile, then the profile will dictate what type of audio transport mechanisms are possible.

For a simple device, such as a voice-quality monophonic phone headset, a simple SCO audio channel must be available. When not precluded by extraordinary conditions, the device should allow all SCO audio packet types to be used and leave the exact selection to the BT chip's link-manager code.

If the headset supports higher-quality audio, such as wideband speech, eSCO capability must be added, as well as an appropriate codec to handle data decoding. Be aware that the profile layer code must manage the channel-feature negotiations. This differs from the simpler SCO channel, which requires no negotiation at the profile layer.

If the two devices can't agree on a set of eSCO parameters, they must be able to back off and use an SCO channel. This added negotiation capability increases code complexity, and interoperability difficulties are more likely. Manufacturers of products containing eSCO capabilities would do well to perform as much interoperability testing as possible during the development of these products. This includes testing with Bluetooth 1.1-based products, which don't support eSCO at all.

The operating environment must be factored into the big picture as well. If there are known sources of interference, an 802.11b node for example, a combination of adaptive frequency hopping and eSCO packet retransmission will greatly decrease packet loss and consequently increase audio quality. If the 802.11b node is a part of the same device that contains the Bluetooth node, the designer should be aware that mechanisms exist in hardware and software to implement coexistence strategies.

Bluetooth channel masks can be set by software to avoid the frequencies used by the local 802.11b node. This removes the need for the AFH software to learn through experience those channels that are bad. There are other mechanisms that try to allocate transmit time to each device in turn. This scheme works better with non-time-critical data and may not provide much value when faced with synchronous or isochronous data streams. Since these features differ between chip makers, interested designers should investigate what's available from their preferred suppliers.

Codec choices should be made with care. For SCO and eSCO channels, CVSD combines reasonable audio quality with robustness in the face of potentially flawed data. Using a different codec could well improve audio quality using the same data rate, but data reliability and device interoperability must be considered.

If an application requires a high-quality unidirectional audio path, A2DP is the logical choice. Again, the designer must take care in selecting the codec. For dedicated partner devices, such as a remote speaker that will only connect with its partner node- connected to the audio source-any codec may be used. If the device is expected to interoperate with a wider array of partners, the default codec may be the best choice.

Hopefully, this article has provided some insight into the choices for Bluetooth audio transmission. For more in-depth information, interested readers should consult the Bluetooth specifications or the documentation for their particular stack implementation.