integrate stereo and voice in one Bluetooth device (2)

It’s in the implementation
Let us now comprehend the other piece of the puzzle—the mobile phones.

In the mono world, mobile phone vendors adopted a simple approach of maximizing voice quality and justifiably so. Today there are more than 100 million phones with Bluetooth support.

Unfortunately, they vary widely in their Bluetooth voice implementation. For example, some mobile phones require ACL + SCO connection to be established upon call arrival, while some require the ACL link to be always on, and the SCO link to be established only on call arrival; others choose to have the SCO link always on.

In addition, the SCO packet type (HV1, HV2, HV3) supported by the mobile phone can vary between vendors as well as between models from the same vendor. This is shown in Figure 6.

6. Scenarios to be addressed for Bluetooth voice depending on mobile phone.

Figures 7 and 8 show the sequence chart for ACL link on call arrival and ACL link always on.

7. ACL link on call arrival.

8. ACL link always on.

Real life configurations for the music player and mobile phone that the Bluetooth stereo headset designer needs to address stem largely from implementation decisions taken by either or both the music player and mobile phone vendor.

Imagine a case where AVRCP Pause / Play is implemented using A2DP Suspend / Start, and the mobile phone has the ACL Link Always On (SCO Link on Call Arrival) and supports only HV1 packet.

If the Bluetooth stereo headset was streaming music at say 350 kbps bit rate, any request for SCO connection with HV1 packet type will be rejected by the Bluetooth baseband in the Bluetooth stereo headset.

This is because HV1 packet type requires the entire bandwidth – HV1 packet is a single slot packet type carrying 10 bytes of information and needs to be transmitted once in every two time slots; the piconet master needs 1 slot to send the HV1 packet and the next slot to receive the HV1 packet – effectively taking up the entire bandwidth.

In the presence of an existing ACL link streaming at 350 kbps (which in an ideal world will eventually go to Suspend mode upon Call Arrival), the Bluetooth baseband in the Bluetooth stereo headset knows it cannot meet the bandwidth requirement of a simultaneous SCO link with HV1 packet type and rejects the request for SCO connection. This is obviously a big problem for mobile phones that support only HV1 packet type.

Figure 9 illustrates the sequence chart for HV1 SCO packet type connection + suspend / start.

9. Sequence chart for HV1 SCO packet type connection + suspend / start.

Imagine another situation where the Bluetooth mobile phone supports HV3 packet type. The Bluetooth baseband on the Bluetooth stereo headset will accept the incoming connection—the piconet master requires 1 slot to send an HV3 packet, the next slot to receive the HV3 packet; the next 4 slots and hence bandwidth, is available before the master needs to send the next HV3 packet.

However, if the Bluetooth music player has implemented the AVRCP Pause / Play using the Streaming Silence mechanism, the Bluetooth stereo headset will have problem managing an ACL link that is streaming data (silence) and a SCO link simultaneously.

10. Sequence chart for HV3 SCO packet type + streaming silence.

Another problem caused by less than ideal implementation is the handling of button press. There are instances when the mobile phone streams beeps for any button press on the SCO link when music is streaming on the ACL link.

The user experience is unpleasant. Whenever a key is pressed, a beep is played out on the Bluetooth stereo headset. This requires pausing the music, switching to the SCO link, playing the beep, resuming the music only to interrupt it again the next time a key is pressed on the mobile phone.

A workaround is to ask the consumer to disable the key pad beeps on the mobile phone. This is both inelegant and expensive. It requires support calls, documentation and user education and is therefore unacceptable.

11. Sequence chart for SCO Beeps on mobile phone.

There are multiple configurations that a Bluetooth stereo headphone and a Bluetooth mono headset need to take care of independently. When both the Bluetooth stereo and Bluetooth mono features need to come together, these configurations multiply leading to increased complexity of the Bluetooth stereo headset design.

Resolving basic options
In the past, mobile phone vendors have made product choices that were justified in the isolated context of the mobile phone use case. One example is opting for HV1 packet type for the best quality audio as compared to HV3 packet type support.

Similarly, Bluetooth music player vendors have made choices that work well in a narrow use case—for example using Streaming Silence for AVRCP Pause / Play. The limitations imposed by such choices are proving to be very expensive in the world of stereo-mono co-existence. The recent formation of AV-HFP working group within the Bluetooth SIG is anticipated to help address this very issue.

Other challenges
There are a host of other systemic issues that need to be addressed in designing a Bluetooth stereo headset. For the sake of completeness, we will briefly touch upon these.

Managing MIPS requirement in single chip solutions during switchover. The MIPS load may shoot up to 90 to 95 percent of the available horsepower in single chip solutions as most Bluetooth basebands are designed optimally for cost. Care must be taken to handle this peak MIPS load. Managing jitter during switchover. While jitter is always a major challenge in wireless streaming, it becomes particularly severe during switchover. Coupled with the peak MIPS load, this becomes a sticky problem to solve. Latency. Latency needs to be as small as possible so as to present a near-wired user experience. There are two components to this – call arrival and resumption of music after call is over. In the first case, if latency is high, the call might be dropped, while in the latter, user might feel that music is being lost during switchover. In either case, user experience suffers.

Conclusion
The requirement of Bluetooth music and voice to co-exist brings to the fore technical and non-technical challenges. The good news is that these challenges are not insurmountable because they relate largely to implementation choices made by individual companies and absence of a cohesive guideline.

These challenges have been recognized and are being addressed. Through co-ordination at the consortium level (Bluetooth SIG) as well as by individual companies, it is possible to convert the potential into a technical and commercial success story.

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 .
Bikash Chowdhury is a Program Manager, Wireless Stereo Program at Impulsesoft. He can be reached at .