首页 > 技术文章 > 基带 > integrate stereo and voice in one Bluetooth device (1)

integrate stereo and voice in one Bluetooth device (1)

52RD.com 2005年10月31日 Yogesh Kamat Mhamai            评论:0条 我来说两句
  Bluetooth stereo is forecast to become the fastest growing Bluetooth application—and the second largest. As a result, designers are bringing Bluetooth and music-on-the-go together with Bluetooth accessories, primarily stereo headphones for streaming music.

This is easier said than done. Multiple challenges must be addressed in order to deliver Bluetooth devices with stereo and music with a compelling user experience. This article discusses these challenges in details and suggests ways of overcoming them.

Bluetooth music—things are bright, but . . .
In the first quarter of 2005, virtually all of the top mobile phone vendors had either announced or launched mobile phones that support music—Nokia announced the N91 model in April, Sony Ericsson launched the Walkman handset at CeBIT in March, Samsung launched the SGHi300 at the same event while Motorola has been making headlines with the iTunes version of its mobile phone.

The good news is tempered by the fact that adoption of Bluetooth stereo headphones has not kept pace with the growth of mobile music.

The reasons are not hard to grasp. With Bluetooth established as the de facto short range wireless standard for mobile phones and the increasing popularity of Bluetooth mono headset, users do not want to carry two Bluetooth audio devices—one for voice (mobile phones) and another for stereo (music player).

Some definitions—to avoid confusion
Bluetooth mono (voice) headsets have been shipping for a while now and have attained a high level of maturity. A Bluetooth mono headset is the small Bluetooth devices that people use for handsfree calls from mobile phones.

A Bluetooth stereo headphone allows users to listen to ONLY stereo music over Bluetooth.

A Bluetooth stereo headset, allows users to take handsfree call as well as listen to stereo music. Switchover refers to the seamless transition in a stereo headset from a music streaming state to a voice-call state and the subsequent return to music streaming once the call is over.

Bluetooth stereo headset—know the product
Multiple user scenarios relate to Bluetooth stereo and Bluetooth voice. Most of them can be reduced to the following:

  • Music player—Mobile phone connectivity
  • Multimedia phone connectivity

Let us look at these two user scenarios in greater detail.

Music player—Mobile phone connectivity
A user is listening to streaming music using her Bluetooth stereo headset. She gets a call on her mobile phone. Music pauses automatically and she hears ring tones on the headset; she decides to take the call. As soon as she hangs up, music resumes from where it had paused.

The above user scenario would most likely require the Bluetooth stereo headset being the common device in two piconets. The mobile phone will be the master in one of the piconets, and the music player will be the slave in the other piconet.

The Bluetooth stereo headset itself would be the master in one piconet and slave in another, resulting in a scatternet. In some cases, it is possible that scatternet may not be created, in which case the Bluetooth stereo headset will be the master.


1. Example of a scatternet.


2. Example of a piconet.

Multimedia phone connectivity
A user is enjoying wireless music using his latest Bluetooth mobile phone that supports music. His phone shows an incoming call; music pauses on the phone, and consequently, on the Bluetooth stereo headset. He takes the call using the Talk button on the Bluetooth stereo headset. As soon as he hangs up, music resumes automatically from where it paused. This creates a simple piconet with two devices.

Both the applications look deceptively simple—pause the music, take the call and resume music once the call terminates. In reality it is not as simple as it sounds. Iintegrating voice and stereo capability in a Bluetooth headset while delivering a simple and intuitive user experience is fraught with challenges. Such challenges can be categorized as:

  1. Technical: These relate to Bluetooth specification that either does not adequately address the issue or is ambiguous. For example, it is impossible to establish an HV1 SCO link for taking a call when an ACL link for streaming music already exists. The HV1 packet type will need the entire bandwidth.
  2. Implementation:These relate to problems arising out of interpretation of the specification and subsequent implementation of the mandatory or optional features in a profile. For example, many mobile phones establish a SCO connection every time a key is pressed on the mobile phone. This creates a frustrating user experience when streaming music needs to be paused every few milliseconds so that the key press on the mobile phone can be rendered on the Bluetooth stereo headset.
  3. Absence of guidelines – These relate to [1] and [2] above. Since the specification may be inadequate or ambiguous at times and a large number of companies are rushing to implement them in their products, a set of guidelines for co-existence of Bluetooth voice and music is urgently needed. Only recently have the Bluetooth SIG and companies realized the tremendous opportunity that Bluetooth stereo headset applications present. Multiple initiatives are underway to address the issue of co-existence and interoperability for Bluetooth stereo and voice features.

Let’s look at each of the above challenges in detail.

It’s not in the technology
The Bluetooth stereo headset is the center of the integrated universe. In the case of music player – mobile phone connectivity, the Bluetooth stereo headset is the connecting link between the mobile phone and the music player; in the case of multimedia phone connectivity, even though the mobile phone may be aware of both the links—SCO and ACL—the Bluetooth stereo headset has a critical role to play in managing the switchover.

As discussed earlier, the user experience involves pausing the music, playing the ring tones on the headset and depending on user’s preference, dropping or taking the call, and finally resuming music once the call is complete. Bluetooth stereo headphones have handled the pause and resume sequence, in isolation. Similarly, the voice sequence has been handled well, in isolation, by Bluetooth mono headsets. The challenge comes in putting these features together.

To begin with, the semantics of Audio-Video Remote Control Protocol (AVRCP) commands Pause and Playy are not tightly linked with Advanced Audio Distribution Profile (A2DP) connection. Currently, one of the following three options are adopted by music players incorporating Bluetooth stereo in their system, when they receive a Pause command:

  1. Suspend / Start
  2. Disconnect / Connect
  3. Streaming silence

Suspend / Start is the ideal implementation for the AVRCP Pause and Play command. This is shown in Figure 3.


3. AVRCP Pause / Play implemented using A2DP Suspend / Start.

Unfortunately, Suspend / Start is an optional command in A2DP and not implemented in a large number of solutions. This leads to a situation where one of the following is used as a workaround.

Disconnect / Connect is a mandatory command and does not suffer from the issues faced by the optional Suspend / Start command. This option is shown in Figure 4.


4. AVRCP Pause / Play implemented using A2DP Disconnect / Connect.

This approach suffers from two major drawbacks. The semantics of AVRCP Pause / Play do not exactly correspond to Disconnect / Connect. It also results in higher latency due to protocol negotiation for reconnection – all codec parameters are negotiated afresh, as though it is a new connection.

Streaming silence is another approach that can be adopted to implement the semantics of AVRCP Pause / Play. When the Bluetooth stereo headset invokes the AVRCP Pause command, the Bluetooth music play can start streaming silence so that to the end user music appears to have been paused. This option is shown in Figure 5.


5.AVRCP Pause / Play implemented using Streaming Silence.

This, in reality, is a simulation of AVRCP Pause / Play. This might be a workable alternative, when Suspend / Start is not implemented, and the latency associated with Disconnect / Connect may be too high for an acceptable user experience.

It is important to note that independent of the method adopted to implement the semantics of the AVRCP Pause / Play, the end user may not experience true Pause / Play behavior ie. music resumes from exactly where it had stopped, unless the Bluetooth AV subsystem has:

  1. A digital interface to the music player, and
  2. A programmatic interface for controlling the state of the music player

All this leads to the following conclusion. There is no consistent approach adopted by Bluetooth music players for addressing the AVRCP Pause / Play semantics The lack of agreed upon guidelines increases the design and implementation complexity for the Bluetooth stereo headset.

 About the authors
Yogesh Kamat Mhamai is a Senior Software Engineer at Impulsesoft. Yogesh has been involved in developing one of the world''''''''''''''''s first Bluetooth stereo headset solutions. He can be reached at yogesh@impulsesoft.com.
Bikash Chowdhury is a Program Manager, Wireless Stereo Program at Impulsesoft. He can be reached at bikash@impulsesoft.com.

(52RD.com)
读取...
相关报道
评 论
文章导航 Navigation
精彩评论 Commentmore...
赞助商链接 Support
特别推荐 Recommend