HFP for Linux Bluetooth Hands Free

**samr7** · 11-14-2008, 12:40 PM

Originally Posted by zenetti

I guess you would be interested in some feedback from my recent trials (revision 32). Baseline system is Ubuntu 8.04 with standard kernel (2.6.24-21), Bluetooth USB Dongle is a Belkin F8T016ng (BCM2046 afaik), the phone a good old Nokia 6310i.

1) First try with Ubuntu 8.10 (intrepid) and Bluez 4.17:

No chance in getting the AG connected, the connection was immediately released afer it had been established. A simple test with "rfcomm connect 0 <bdaddr>" showed that an RFCOMM connection may be established in principle (channel 1 is DUN). However, for "rfcomm connect 0 <bdaddr> 13" where channel 13 is the HFAG service, the connection was established and immediately released. So nothing nohands specific, but probably some weird Bluez 4.x glitches. Switched back to hardy for that reason...

Hi zenetti,

Thanks for trying it out! I'm sorry you ran into so many problems.

Regarding Ubuntu 8.10, I just installed it on a VMware instance and am trying to get HFP to work. I definitely feel your pain here, and will post more when I get up to speed with the changes that were made to the BlueZ environment.

Originally Posted by zenetti

2) HFP Build:

Worked quite well after I had installed all dependencies. The only thing I am still struggling with is how to make the doxygen manuals. configure is happy with my system but the makefile won't build the manuals. Any clues? Also, "make distcheck" breaks with *** No rule to make target `soundtest.cpp', needed by `distdir'. Stop. Probably nothing to be worried about, just to let you know.

I wasn't even aware that there was a 'make distcheck' target.

Anyway, the build system is indeed a mess, so I just committed some changes to try to clean it up a little bit. The 'dist' and 'distcheck' targets ought to work now.

Originally Posted by zenetti

3) Microphone problems and sound quality:

Getting the sound capturing (microphone) to work properly has been a pain. On my IBM T43 Laptop, the microphone seems to be quite weak, even with full amplification settings in GNOME's Volume Control (built-in sound: Intel ICH 6). I got it to work really good this afternoon (still don't know how exactly), but after I had shut down Linux and started over again, the old microphone weakness reappeared.

That sounds like flaky support for your laptop's codec chip in the sound driver. Are you using snd-hda-intel?

It can take a _lot_ of time and effort to get to the bottom of this type of problem.

Originally Posted by zenetti

Another strange thing (hardly reproducable) is that when connected, I sometimes hear only a strong noise at the far-end side (my desktop phone) and a lot of echo (with all libspeexdsp setting turned off). Killing all left-over instances of hfpd often helps, but not always. In this case a reboot might do the job.

Whoa there disco stu! Please confirm:

You are able to get HFP stuck in a state with degraded audio quality compared to when you first start hfpd/hfconsole
The state occurs with all DSP options disabled
The state persists across starting/stopping hfconsole
The state can be fixed by killing hfpd and having it automatically restarted when hfconsole is next started

Is this all correct? How have you managed to get it into this state? Can you characterize what happens before it gets into this state?

Originally Posted by zenetti

Finally, I do experience the same problem as duxa above. While I can transfer voice from my desktop phone to the Laptop speakers, the reverse link shows silence. When speaking into the Laptop's microphone, I can hear myself in the loudspeakers (or some earphones to avoid any cross-coupling), but no SCO "uplink" transfer seems to occur. Same as for duxa, my hcidump reports that only incoming SCO packets are present.

How often, when you run hcidump, do you not observe any outbound SCO data packets? Is it _every time_ or just some of the time?

Also, to be clear, you're seeing only "> SCO data:" and not "< SCO data:" in the hcidump output?

If you're truly not seeing any outbound SCO data packets, then I'm even more puzzled by the problem you described above with degraded audio quality, and am not sure where the audio being sent to your desk phone would be coming from, including its noise and echo. Also, if hfpd is truly unable to send any audio packets out over Bluetooth, it's unclear why killing and restarting hfpd would fix that problem.

Right now, hfpd/hfconsole lack any indication of audio loss. If this condition were characterized to the user, it might be easier to debug the problems you're encountering. I'll see what I can do to communicate this better.

I did get an strace from duxa. It confirmed that for his instance of the problem, hfpd is submitting the outbound audio data to the kernel socket buffer, but for whatever reason, the buffer isn't being emptied. The root cause is still unknown.

**zenetti** · 11-17-2008, 03:43 PM

Hi Sam,

good news on nearly all the issues of my last posting.

It seemed that my BT dongle (Belkin F8T016ng with Broadcom chipset) has been too new for the bluez 3.xx drivers. It did work but apparently not stable enough. hciconfig -a issued an input/output error after system (re)start and required a "sudo hciconfig hci0 reset" in order to reset it. While this fixed the access problem (hciconfig -a succeededl), some further hidden problems were probably causing the SCO losses.

I switched back to an older (and more common) Belkin F8T012 dongle (BCM as well) which worked out of the box. Interestingly, all the microphone problems have disappeared and voice is now true duplex. There still a little echo which may need some further dsp tuning.

Next, I compiled and ran hfstandalone. First, the link broke immediately after the connection had been established (before any call was possible). I cleaned up everything and set LD_RUN_PATH to /usr/local/lib where libspeexdsp is installed (does not yet come with Ubuntu 8.04) and re-compiled. Now the app's initilization was successful.

However, shortly after a call was established, the connection dropped out again:

Code:

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 Voice: 0x0060
Destroying record for Nokia 6310i

It's strange so far as I do not observe this error from hfconsole.

I don't think that it might be due to the dongle again, but it would anyhow be worthwhile trying a dongle with a different chipset (preferably CSR Bluecore 4). Do you have any recommendations? According to your sourceforge page, the CSR chipset seems to be the most stable and reliable one.

Thanks a lot!

**goroX** · 11-18-2008, 10:38 AM

I need a bluetooth dongle so that I can help testing in some sort with my blackberry.

**sancho_sk** · 11-22-2008, 10:28 AM

I like it a lot.
Unfortunately it does not work correctly with my cell, but to see that someone is working on such functionality is GREAT!
I can offer testing for it, I am not so good in programming, but I have multiple BT USB dongles and multiple cellphones for testing.

**gazza_d** · 11-24-2008, 06:56 AM

Hi

Myself and others have been attempting to see if your HFP app for linux will compile and run on a Nokia Internet Tablet (N800 and N810). The forum thread covering this is here http://www.internettablettalk.com/fo...ad.php?t=18868

Another forum member "Mrweasel" has managed to compile the code, with some minor changes, and hfpd, and hfconsole will start on the tablet, and connect to phones. I'm using a Nokia 6120. detection and connection works fine, as does dialling as well. Audio does not work yet, there possibly could be differences between the tablet and desktop linux.

Below is the output running hfconsole, and connecting to my phone. As you can see there are still some code issues to be resolved. Is there anything obvious which looks like a showstopper. Although I can hack about with VB, I am not a linux coder at all, and a lot of this is beyond me.

Thanks very much for giving hope. Tablet users have been crying out for an app like this for a very long time.

Regards

Gary

Nokia-N800-36-5:/usr/bin# hfconsole
python[1781]: GLIB WARNING ** libglade - unknown property `program_name' for class `GtkAboutDialog'
python[1781]: GLIB WARNING ** libglade - could not convert string to type `GStrv' for property `authors'
/usr/bin/hfconsole:220: Warning: gsignal.c:1617: signal `file_set' is invalid for instance `0x25f050'
self.widgets.signal_autoconnect(dic)
HFPD: HCI Command status: 0x00 0x01 0x0405
HFPD: HCI Command status: 0x00 0x00 0x041b
HFPD: HCI Command status: 0x00 0x01 0x0000
HFPD: HCI Command status: 0x00 0x01 0x0419
HFPD: HCI Name request complete (0): "00:1D:6E:74:AE:F6" -> "6120"
HFPD: SDP: Supported features: ef
HFPD: << AT+BRSF=15
HFPD: HCI Submit 0x0419
HFPD: HCI Command status: 0x00 0x01 0x0419
HFPD: HCI Name request complete (0): "00:1D:6E:74:AE:F6" -> "6120"
HFPD: >> +BRSF: 239
HFPD: >> OK
HFPD: << AT+CIND=?
HFPD: >> +CIND: ("service",(0,1)),("call",(0,1)),("callsetup",( 0-3)),("call_setup",(0-3)),("callheld",(0-2)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5))
HFPD: >> OK
HFPD: << AT+CMER=3,0,0,1
HFPD: >> OK
HFPD: << AT+CLIP=1
HFPD: >> OK
HFPD: << AT+CCWA=1
HFPD: >> OK
HFPD: << AT+CHLD=?
HFPD: >> +CHLD: (0,1,1x,2,2x,3,4)
HFPD: Hold modes: 0 1 1x 2 2x 3 4
HFPD: >> OK
HFPD: << AT+CIND?
HFPD: AG 00:1D:6E:74:AE:F6: Connected
HFPD: >> +CIND: 1,0,0,0,0,5,0,4
HFPD: >> OK
HFPD: HCI Command status: 0x00 0x01 0x0409
HFPD: HCI Command status: 0x00 0x01 0x040f
HFPD: AudioGatewayStart: /net/sf/nohands/hfpd/00_1D_6E_74_AE_F6
HFPD: ** OpLatency: primary open took 15ms
HFPD: ALSA play state: 2
HFPD: ALSA play state: 2
HFPD: ALSA rec state: 2
HFPD: ALSA rec state: 2
HFPD: Pump: packet size = 24
HFPD: Pump: input max fill = 320
HFPD: Pump: bot packet size = 160
HFPD: Pump: bot min fill = 320
HFPD: Pump: bot max fill = 640
HFPD: Pump: top packet size = 24
HFPD: Pump: top min fill = 48
HFPD: Pump: top max fill = 96
HFPD: Pump: watchdog timeout = 500
HFPD: Echo tail: 800
HFPD: ALSA play state: 2
HFPD: ALSA rec state: 2
HFPD: SoundIoPump Stopped
HFPD: Spontaneous audio stream halt
HFPD: ** OpLatency: async process overall took 57ms
HFPD: HCI Command status: 0x00 0x01 0x0406
Traceback (most recent call last):
File "/usr/bin/hfconsole", line 1161, in config_driver_changed
devlist = self.soundio.ProbeDevices(drivername)
File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 607, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: Device probe failed

**gazza_d** · 11-24-2008, 07:02 AM

Hi

Myself and others have been attempting to see if your HFP app for linux will compile and run on a Nokia Internet Tablet (N800 and N810). The forum thread covering this is here http://www.internettablettalk.com/fo...ad.php?t=18868

Another forum member "Mrweasel" has managed to compile the code, with some minor changes, and hfpd, and hfconsole will start on the tablet, and connect to phones. I'm using a Nokia 6120. detection and connection works fine, as does dialling as well. Audio does not work yet, there possibly could be differences between the tablet and desktop linux.

Below is the output running hfconsole, and connecting to my phone. As you can see there are still some code issues to be resolved. Is there anything obvious which looks like a showstopper. Although I can hack about with VB, I am not a linux coder at all, and a lot of this is beyond me.

Thanks very much for giving hope. Tablet users have been crying out for an app like this for a very long time.

Regards

Gary

Nokia-N800-36-5:/usr/bin# hfconsole
python[1781]: GLIB WARNING ** libglade - unknown property `program_name' for class `GtkAboutDialog'
python[1781]: GLIB WARNING ** libglade - could not convert string to type `GStrv' for property `authors'
/usr/bin/hfconsole:220: Warning: gsignal.c:1617: signal `file_set' is invalid for instance `0x25f050'
self.widgets.signal_autoconnect(dic)
HFPD: HCI Command status: 0x00 0x01 0x0405
HFPD: HCI Command status: 0x00 0x00 0x041b
HFPD: HCI Command status: 0x00 0x01 0x0000
HFPD: HCI Command status: 0x00 0x01 0x0419
HFPD: HCI Name request complete (0): "00:1D:6E:74:AE:F6" -> "6120"
HFPD: SDP: Supported features: ef
HFPD: << AT+BRSF=15
HFPD: HCI Submit 0x0419
HFPD: HCI Command status: 0x00 0x01 0x0419
HFPD: HCI Name request complete (0): "00:1D:6E:74:AE:F6" -> "6120"
HFPD: >> +BRSF: 239
HFPD: >> OK
HFPD: << AT+CIND=?
HFPD: >> +CIND: ("service",(0,1)),("call",(0,1)),("callsetup",( 0-3)),("call_setup",(0-3)),("callheld",(0-2)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5))
HFPD: >> OK
HFPD: << AT+CMER=3,0,0,1
HFPD: >> OK
HFPD: << AT+CLIP=1
HFPD: >> OK
HFPD: << AT+CCWA=1
HFPD: >> OK
HFPD: << AT+CHLD=?
HFPD: >> +CHLD: (0,1,1x,2,2x,3,4)
HFPD: Hold modes: 0 1 1x 2 2x 3 4
HFPD: >> OK
HFPD: << AT+CIND?
HFPD: AG 00:1D:6E:74:AE:F6: Connected
HFPD: >> +CIND: 1,0,0,0,0,5,0,4
HFPD: >> OK
HFPD: HCI Command status: 0x00 0x01 0x0409
HFPD: HCI Command status: 0x00 0x01 0x040f
HFPD: AudioGatewayStart: /net/sf/nohands/hfpd/00_1D_6E_74_AE_F6
HFPD: ** OpLatency: primary open took 15ms
HFPD: ALSA play state: 2
HFPD: ALSA play state: 2
HFPD: ALSA rec state: 2
HFPD: ALSA rec state: 2
HFPD: Pump: packet size = 24
HFPD: Pump: input max fill = 320
HFPD: Pump: bot packet size = 160
HFPD: Pump: bot min fill = 320
HFPD: Pump: bot max fill = 640
HFPD: Pump: top packet size = 24
HFPD: Pump: top min fill = 48
HFPD: Pump: top max fill = 96
HFPD: Pump: watchdog timeout = 500
HFPD: Echo tail: 800
HFPD: ALSA play state: 2
HFPD: ALSA rec state: 2
HFPD: SoundIoPump Stopped
HFPD: Spontaneous audio stream halt
HFPD: ** OpLatency: async process overall took 57ms
HFPD: HCI Command status: 0x00 0x01 0x0406
Traceback (most recent call last):
File "/usr/bin/hfconsole", line 1161, in config_driver_changed
devlist = self.soundio.ProbeDevices(drivername)
File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 607, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: Device probe failed

**samr7** · 11-24-2008, 02:03 PM

Originally Posted by zenetti

It seemed that my BT dongle (Belkin F8T016ng with Broadcom chipset) has been too new for the bluez 3.xx drivers. It did work but apparently not stable enough. hciconfig -a issued an input/output error after system (re)start and required a "sudo hciconfig hci0 reset" in order to reset it. While this fixed the access problem (hciconfig -a succeededl), some further hidden problems were probably causing the SCO losses.

Hi zenetti,

Ouch! Sorry to see it break so badly. I'll put BCM2046 down as questionably supported.

BTW, which kernel are you using that has such problems with BCM2046?

Originally Posted by zenetti

Code:

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 Voice: 0x0060
Destroying record for Nokia 6310i

It's strange so far as I do not observe this error from hfconsole.

Hmm. See if you can capture some hcidump output. This looks like a flaky dongle or phone.

If hfconsole isn't tickling this problem, then it is possible that it is being caused by hfstandalone initiating the SCO connection. hfconsole currently does not initiate SCO connections and depends on the phone to do this. I have two Motorola phones that seem to have their Bluetooth flake out every other time the PC initiates a SCO connection, but are also quicker at initiating connections than hfstandalone is, so that hfstandalone doesn't normally tickle the bug.

Originally Posted by zenetti

I don't think that it might be due to the dongle again, but it would anyhow be worthwhile trying a dongle with a different chipset (preferably CSR Bluecore 4). Do you have any recommendations? According to your sourceforge page, the CSR chipset seems to be the most stable and reliable one.

That's right, CSR FTW! The CSR dongles appear to be some combination of having the fewest serious bugs and having the best BlueZ kernel support. I have a few CSR dongles, a BCM2035, and an ISSC. The ISSC dongle appears to work well, but on rare occasion, will spontaneously drop a SCO connection during a call with my Motorola phone. The BCM2035 is similar, but when it fails, it completely flakes out and triggers a USB reset. I've never seen any of this with a CSR dongle.

**samr7** · 11-24-2008, 02:11 PM

Originally Posted by sancho_sk

I like it a lot.
Unfortunately it does not work correctly with my cell, but to see that someone is working on such functionality is GREAT!
I can offer testing for it, I am not so good in programming, but I have multiple BT USB dongles and multiple cellphones for testing.

Hi Sancho,

Thanks for trying it out! I got your private mail. Ouch, we'll see what can be done about prefixing phone numbers with '+'.

**zenetti** · 11-25-2008, 03:55 PM

Originally Posted by samr7

Hi zenetti,

Hi Sam,
I've seen that you made quite some changes to the code in the meantime (latest revision is 42). I do really appreciate your work here.

Originally Posted by samr7

Ouch! Sorry to see it break so badly. I'll put BCM2046 down as questionably supported.

BTW, which kernel are you using that has such problems with BCM2046?

I am running either Ubuntu 8.04 or 8.10 with "OEM" kernels, that is, 2.6.24-21 and 2.6.27-8, respectively. Most of my tests were on Ubuntu 8.04, for which the BCM2046 chipset seemed too new for the drivers. On Ubuntu 8.10 under VMware (runnning on an XP host), I had the problem that no connection to the Bluetooth audio gateway was possible (channel 13 in my case). Nevertheless, an RFCOMM to channel 1 (Dial-up Network) did work.

As a remark, all of my recent test experience applies to a native Ubuntu installation. Runnning Ubuntu in a Virtual machine on my IBM T43 always gives me choppy sounds, which is likely due to a non-proper sync timing between client and host.

Originally Posted by samr7

Hmm. See if you can capture some hcidump output. This looks like a flaky dongle or phone.

If hfconsole isn't tickling this problem, then it is possible that it is being caused by hfstandalone initiating the SCO connection. hfconsole currently does not initiate SCO connections and depends on the phone to do this. I have two Motorola phones that seem to have their Bluetooth flake out every other time the PC initiates a SCO connection, but are also quicker at initiating connections than hfstandalone is, so that hfstandalone doesn't normally tickle the bug.

I had to read the last few pages of this thread more carefully to see that my Broadcom USB Dongle (the one with BCM2035) was causing the same USB disconnect/reconnect problem as reported by duxa. /var/log/messages contained the respective log messages. Because of this, it was nearly impossible to establish a stable call. Either immediately after call setup, or shortly thereafter, the pipe broke completely.

Originally Posted by samr7

That's right, CSR FTW! The CSR dongles appear to be some combination of having the fewest serious bugs and having the best BlueZ kernel support. I have a few CSR dongles, a BCM2035, and an ISSC. The ISSC dongle appears to work well, but on rare occasion, will spontaneously drop a SCO connection during a call with my Motorola phone. The BCM2035 is similar, but when it fails, it completely flakes out and triggers a USB reset. I've never seen any of this with a CSR dongle.

I finally ordered a Fujitsu Siemens Bluetooth V2.0 Dongle with CSR BlueCore4-external chipset. This works by far better than the Broadcom dongles. I still did get rare disconnects with broken pipe (as of nohands revision 38), but haven't checked yet whether the dongle got disconnect in this case. This probably could have also caused by extensively playing around with the sound configuration, changing buffer and packet parameters maybe too frequently.

In any case, my sound system doesn't seem to be properly configured for HFP, but unfortunately I cannot nail down the problem. ALSA mixer basically gives me more drops and silence paddings than OSS for instance. In the beginning I also wasn't able to adjust the packet size for ALSA which had been 21 ms default (period_size 1024 at 48 kHz sampling rate). To make tweaking possible, either some little entries in .asoundrc or using plughw:0 was needed. Using the raw device seems to solve a lot of problems for me and I still have to check whether this is the key.

However, another thing makes me wondering. While nohands works basically quite fine with my Nokia 6310i (where I recently flashed a new firmware to exclude any potential glitches from this kind of bug source), some phones of colleagues of mine do completely freeze the whole system. I have seen this perfectly reproducible deadlock for two Sony-Ericsson K610i's and a Samsung U-900. On the other hand, a Sony-Ericsson P990i worked quite well even for the BCM2035 dongle.

The system freeze occurs immediately after pressing the Dial button, i.e., when trying to setup the audio connection. This locks the system completely and the CapsLock indicator starts flashing. No input is possible anymore and a cold shutdown is required. Interestingly, the problem is quite similar to this one

http://ubuntuforums.org/archive/index.php/t-424794.html

...and others which a have found on the web, unfortunately all without a solution provided.

**samr7** · 11-26-2008, 02:08 AM

As a heads-up, I just fixed a serious one-line bug that was preventing a connection with my loaner BlackBerry.

Over the past week, a number of other changes related to audio diagnostics and error reporting have also gone in. The hfconsole program is now able to report specific streaming audio problems, including sound card / Bluetooth timeouts and failures, clock skew, and buffer overrun/underrun events.

Sadly, there is still no phone book, nor any other major new features. Those will come once the basic functionality becomes more stable.