Thread: HFP for Linux Bluetooth Hands Free

i tried with an external bt-usb-dongle. same error.
if i deactivate "Output Buffer" i do not get this error.

now the connection is stableand everything is working fine.

great tool!!! now we need to read the phonebook and sms from the phone and windows will leave my carpc forever.

i can not tell you how happy i am about this.

sorry for posting the same thing twice!!

samr7,

First, thanks so much for starting this up! I've been looking for this functionality for what seems like forever...I had found someone who started a similar project a year or three ago but I could never get the software to work and it was, of course, abandoned :/
I am using an IOgear USB bluetooth adapter (Broadcom bcm2045) with a "Razr" V3X. I've tried both the gtk and qt frontends that are supplied (using svn rev 25 now). If I use the gtk frontend (hfconsole) I find that I have difficulty pairing with the v3x if I initiate pairing from the computer. If I pair from the phone it seems to work, although it doesn't appear to ever open the audio device on the computer (alsa). If I use the qt frontend (hfstandalone) I can usually pair from the computer, but the only audio I get is the pairing sound that Razrs make, and it is very broken up; any sound after that is not played back. Here is some of the output when running hfstandalone:
SCO TIOCOUTQ: Resource temporarily unavailable
** OpLatency: async process overall took 39ms
**** ALSA playback xrun ****
--snip--
SoundIoPump: Top endpoint watchdog timeout
SoundIoPump Stopped
Audio pump aborted
Read from RFCOMM socket: Software caused connection abort
Involuntary device disconnect!
HCI socket read error: Broken pipe
Bluetooth Failure, hub shut down
SCO MTU: 64:8

Sometimes attempting to pair from the computer results in RFCOMM connect: Connection refused
I should note that the bluetooth adapter does work fine for obex file transfers. I don't believe the driver is in-kernel, rather something that BlueZ supports.

Cheers,
Jesse

Originally Posted by avsa242

I am using an IOgear USB bluetooth adapter (Broadcom bcm2045) with a "Razr" V3X. I've tried both the gtk and qt frontends that are supplied (using svn rev 25 now). If I use the gtk frontend (hfconsole) I find that I have difficulty pairing with the v3x if I initiate pairing from the computer. If I pair from the phone it seems to work, although it doesn't appear to ever open the audio device on the computer (alsa). If I use the qt frontend (hfstandalone) I can usually pair from the computer, but the only audio I get is the pairing sound that Razrs make, and it is very broken up; any sound after that is not played back. Here is some of the output when running hfstandalone:

Hi Jesse,

Thanks for trying it out! I'm sorry the pairing didn't work from hfconsole, and am puzzled why it would work any better in hfstandalone. Can you give some more detail -- did your phone not appear on the hfconsole scan dialog? Were you able to find it and associate it with hfconsole, but attempts to initiate a connection to your phone from hfconsole failed?

Originally Posted by avsa242

SCO TIOCOUTQ: Resource temporarily unavailable

Congratulations, you just pointed out an embarrassing bug. TIOCOUTQ is a feature that needs more testing, and it is only supported on very recent kernels. I'll guess you have 2.6.27+? I just committed a change to fix the ioctl call. Please update and give it another whirl! The above message should never be seen again.

It is possible that TIOCOUTQ is not useful, and the code to use it needs to be removed from libhfp.

Originally Posted by avsa242

** OpLatency: async process overall took 39ms
**** ALSA playback xrun ****
--snip--
SoundIoPump: Top endpoint watchdog timeout
SoundIoPump Stopped
Audio pump aborted
Read from RFCOMM socket: Software caused connection abort
Involuntary device disconnect!
HCI socket read error: Broken pipe
Bluetooth Failure, hub shut down
SCO MTU: 64:8

Sometimes attempting to pair from the computer results in RFCOMM connect: Connection refused
I should note that the bluetooth adapter does work fine for obex file transfers. I don't believe the driver is in-kernel, rather something that BlueZ supports.

How long does the audio connection persist before it breaks like this?

BPM80 above had a similar experience with a built-in Broadcom module on his Acer Aspire system. You probably have a USB disconnect message to go along with it in /var/log/messages, and the dongle must be doing something that causes the USB subsystem to reset it. Regardless, there appear to be incompatibilities with BCM2045 right now. I'm going to start searching for a BCM2045 based dongle for my own testing. In the mean time, do you have any other dongles?

Thanks again!

Originally Posted by BPM80

HFPD: Config warn: Configured output minimum buffer (40) is less than

Originally Posted by BPM80

i tried with an external bt-usb-dongle. same error.
if i deactivate "Output Buffer" i do not get this error.

D'oh! I should have picked up on this!

If you are using ALSA with the dmix plugin, and use the configuration dialog to set the output buffer too small, it will usually fail like this, and only for Bluetooth voice audio, because the packet intervals are a lot smaller there. This needs to be cleaned up.

sam,

Originally Posted by samr7

Hi Jesse,

Thanks for trying it out! I'm sorry the pairing didn't work from hfconsole, and am puzzled why it would work any better in hfstandalone. Can you give some more detail -- did your phone not appear on the hfconsole scan dialog? Were you able to find it and associate it with hfconsole, but attempts to initiate a connection to your phone from hfconsole failed?

Sorry 'bout that...phone's MAC appeared in the search and got resolved to its name just fine...associating with it is where it seems to hit a snag at least sometimes.

Congratulations, you just pointed out an embarrassing bug. TIOCOUTQ is a feature that needs more testing, and it is only supported on very recent kernels. I'll guess you have 2.6.27+? I just committed a change to fix the ioctl call. Please update and give it another whirl! The above message should never be seen again.

It is possible that TIOCOUTQ is not useful, and the code to use it needs to be removed from libhfp.

Ahhh okay...wasn't sure if it was affecting functionality...yup, 2.6.27-gentoo; and hfp r27 fixes that.

How long does the audio connection persist before it breaks like this?

It seems like only a few seconds; like I mentioned in my first post, the only sound that ever gets to the laptop's speakers is the razr's bluetooth pairing sound as it and the computer first associate, which is all broken up...but nothing after that.

BPM80 above had a similar experience with a built-in Broadcom module on his Acer Aspire system. You probably have a USB disconnect message to go along with it in /var/log/messages, and the dongle must be doing something that causes the USB subsystem to reset it. Regardless, there appear to be incompatibilities with BCM2045 right now. I'm going to start searching for a BCM2045 based dongle for my own testing. In the mean time, do you have any other dongles?

Yeah I wondered if it may be just that simple...I know Broadcom is a name that makes most Linuxers who know better wince...I've been through the headaches of the earlier bcm43xx days with their wifi chipsets I don't have any other dongles but there is a Staples in town I can pick another one up at...might be nice to have one for the desktop anyway.

Thanks again!

Thank you for your work!

Cheers,
Jesse

Hi sam,

I checked my dongle chip type, and it's Cambridge Silicon (lsusb says "ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)"). So if you know that the dongles don't have any other variables than the chip, I suppose the fault lies somewhere else.

I also tried with another, older Nokia phone (6630), but there were the same problems there (the other side's voice is audible but garbled, also mic doesn't work).

I guess I'll play with the buffer etc settings some more, and start studying bluetooth stuff.

Originally Posted by duxa

I checked my dongle chip type, and it's Cambridge Silicon (lsusb says "ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)"). So if you know that the dongles don't have any other variables than the chip, I suppose the fault lies somewhere else.

I also tried with another, older Nokia phone (6630), but there were the same problems there (the other side's voice is audible but garbled, also mic doesn't work).

Hi duxa,

This is an interesting result, and it certainly sounds like the problem you're seeing runs a lot deeper than the dongles.

In light of the TIOCOUTQ problems, you wouldn't happen to be using kernel 2.6.27+ would you? In your previous post with the console output, the typical error message was missing, so probably not? If you are, then there might be a quicker fix. TIOCOUTQ isn't ready for prime time and just needs to be turned off. I'd like to commit the change right now but the Sourceforge SVN server seems to be inaccessible, so I'll post back when it's in.

If you are feeling adventurous, you can edit libhfp/soundio-pump.cpp, line ~569, and set loss_debug = true. If you rebuild hfpd and run it like this, it should dump log messages whenever the audio pump drops or pads samples for whatever reason. This might at least give some clues.

I just committed a change to disable TIOCOUTQ support. Jesse, duxa, please let me know if this helps at all. Thanks.