Bluetooth headset delay issue

[The PocketTV Team]

Apparently, based on user reports, some bluetooth headsets (A2DP i.e. stereo profile) or bluetooth drivers introduce an important audio delay (1/4 to 1/2 sec) which causes audio to appear out-of-sync with video when playing movies or other audio-video content (e.g. games).

This is clearly not a problem when having a phone conversation or listening to music.

But with video, this causes a serious issue and, from what we heard, it affects all applications that rely on audio-video being sync'ed, including Microsoft's own media player. Any audio delay >= 0.1 sec is very noticeable with lip-sync (the maximum acceptable delay is generally considered to be 2 frames at 30 frames/sec, i.e. 0.06 sec).

This audio delay is caused by buffering of audio samples after they have been output by the audio driver (the delay in the audio driver itself is not a problem since there is an API to determine the number of audio samples in the driver's FIFO).

Our understanding is that the audio delay observed with a bluetooth headsets can be a combination of a buffering delay in the device itself (in the bluetooth driver) and possibly another buffering delay in the bluetooth device (headset) itself. Those two delays that add-up can naturally depend on the device (presumably different bluetooth drivers can introduce different delays depending on their buffering), and on the model of bluetooth headset.

Apparently some video applications have implemented a workaround where the user can manually correct the "audio delay" in the application (e.g. using a slider or entering a number), but this is definitely not a user-friendly solution.

Our questions are the following:

- Is there an API to determine if a bluetooth headset is being used? (there is a bluetooth API but i couldn't find a tutorial explaining how to determine if a bluetooth device using the profile A2DP is being used, in C++)

- Is there an API that applications can use to determine this exact additional total audio delay with the A2DP bluetooth headset that is being used? (i.e. the buffering delay in the bluetooth driver on the device, and any additional buffering delay in the bluetooth headset itself)

- What is the solution that Microsoft recomends to mobile video / games applications developers for dealing with this Bluetooth audio delay issue?

-- The PocketTV Team

[Dan East]

I would really doubt there is a method to query a headset to see if it has a delay. Possibly if there is some sort of loopback capability you could measure the round-trip latency and divide by two. Otherwise, you're pretty much asking the hardware if it sucks or not, which is something I doubt the manufacture would want to quantify and report.

The first thing I would try to correlate is the delay verses what type of bluetooth stack the device has. It could be that on the device side the problem is specific to either the Microsoft of Widcomm stacks.

Try creating a bluetooth socket, if that succeeds then the device should have the Microsoft stack. Otherwise it is probably Widcomm (but I've heard hints that there are other BT stacks besides those).

Code: Select all

1  2  3  4  5	SOCKET s = socket (AF_BT, SOCK_STREAM, BTHPROTO_RFCOMM); if (s!=INVALID_SOCKET) {   //Assume ms stack   closesocket(s); }
	5 lines; 1 keywds; 0 nums; 15 ops; 0 strs; 1 coms    Syntactic Coloring v0.4 - Dan East

Here are devices I know of off the top of my head:
Axim x50v: Widcomm
Axim x51v: MS
Asus a716: Widcomm
Treo 700w: MS

Dan East

[The PocketTV Team]

Thanks for your comments.

Otherwise, you're pretty much asking the hardware if it sucks or not, which is something I doubt the manufacture would want to quantify and report.

Well, i don't think the existence of a buffering delay means that the hardware sucks. Maybe buffering is necessary for implementation, e.g. to recover from packet loss.

The problem is just that we need to know the delay.

You are correct, it is possible that most of the delay is caused by the bluetooth stack/driver on the device, rather than by the headset hardware itself.

Nonetheless, MSFT should provide a way to get this audio delay programatically so that applications don't have to guess what bluetooth stack is used, what version of it, and try to hard-code the delay in each situation. This is definitely not the right way to resolve the issue (except as a temporary workaround until MSFT wakes-up to the problem).

Also, i don't think we can afford to purchase all those devices and test them to figure-out the bluetooth audio delay on each of them. That would cost thousands of dollars to do that.

By the way, FYI, one of the devices where a noticeable audio delay was observed is the O2 Atom (Pocket PC) with the Motorola Bluetooth stereo headset (s705).