I'm rethinking the conclusion that many of us had assumed on the cause of poor audio reception at times when using a BT headset as the audio input/output for a PC. The issue seemed to be associated with high CPU usage; therefore, resulting in the intermittent static and break-up in the headset's connection. But, I also noticed that my connection became unusable while trying to use my headset with P2P internet applications like Yahoo Messenger and NetMeeting.

At a recent IT conference, it was explained that the Bluetooth protocol uses two distinct links in its transmission of data. SCO which is mainly used for audio transmission and ACL which is used for the synchronization of data. The theoretical transmission of data for Bluetooth at 1 Mbps (in reality more in the 740 range) is associated with the ACL link only. The SCO has a maximum of only 64 kbit/s.

Since streaming CD quality audio is around 1.4 Mbps, the ACL link is the only route that can provide the bandwidth to achieve this. Obviously, there would have to some kind of compression on one end and buffering/decompression capability on the headset to finally support this transmission rate.

Perhaps, the problems with the headset profile is not CPU, but bandwidth limitations of the SCO?? AFAIK, none of the headsets on the market have any type of real buffering capability. It's really never been necessary to connect with a mobile phone.

It was also suggested that Microsoft's offering of limited services with its BT keyboard and mouse was an indication of its direction to focus its efforts on the use of the ACL link and its bandwidth. All three utilize the ACL only. If you wanted to provide channel stereo via Bluetooth, what better profile than the HCRP??