Page 6 of 11 FirstFirst 1234567891011 LastLast
Results 51 to 60 of 106

Thread: HFP for Linux Bluetooth Hands Free

  1. #51
    Newbie
    Join Date
    May 2007
    Posts
    27
    perhaps we do not need to make our own frontend.

    nghost is very skinable. perhaps you can only provide commandline-apps to make different things with arguments (accept call, dial ...) and we design a skin with the buttons for nghost linked with the right commands.

    what do you think?

  2. #52
    Newbie
    Join Date
    May 2007
    Posts
    27
    sorry for my last post. now i had a look at the openice forum and saw that you are already working on the integration into nghost.

    you are my hero!

  3. #53
    Newbie
    Join Date
    Nov 2008
    Posts
    6

    Thumbs up

    sam,

    hfstandalone for me still behaves the same way, but low and behold, hfconsole now works! Lots of xruns from ALSA, and it's greatly affected by any system activity (maybe I just need to fool with the audio buffer settings?) but it works! I tried testing it with my voicemail (haven't tested it with a live call so I don't know if the mic works, or is supposed to yet) and the sound quality is nice and clear, the dialpad works as expected, call status is reported...that one change seems quite significant I'll attach the output of hfpd in case its of any use.

    Cheers
    Attached Files Attached Files

  4. #54
    Newbie
    Join Date
    Oct 2008
    Posts
    7
    Quote Originally Posted by samr7 View Post
    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.
    Nope, I'm using 2.6.22 (Ubuntu stock). I tried your fix from svn but it didn't help.


    Quote Originally Posted by samr7 View Post
    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 did this and made a call to my voice mail, the console output is attached. There are a lot of discards and padding.
    Attached Files Attached Files

  5. #55
    Newbie samr7's Avatar
    Join Date
    Mar 2006
    Posts
    42
    Quote Originally Posted by avsa242 View Post
    sam,

    hfstandalone for me still behaves the same way, but low and behold, hfconsole now works! Lots of xruns from ALSA, and it's greatly affected by any system activity (maybe I just need to fool with the audio buffer settings?) but it works! I tried testing it with my voicemail (haven't tested it with a live call so I don't know if the mic works, or is supposed to yet) and the sound quality is nice and clear, the dialpad works as expected, call status is reported...that one change seems quite significant I'll attach the output of hfpd in case its of any use.
    Hi Jesse,

    I'm glad you found a solution that made voice operation semi-stable! Does it affect the dropped sample problem if you increase the output buffer setting to, say, 50ms? What kind of machine are you using it on? Your problem is starting to sound more like a scheduler latency issue than a Bluetooth or ALSA issue.

    There are some minor differences in how hfstandalone directs the connection vs. hfconsole. hfconsole won't initiate any voice connections, whereas hfstandalone will. I'll commit some changes to make hfstandalone behave more like hfconsole.

    Thanks!

    Quote Originally Posted by duxa View Post
    Nope, I'm using 2.6.22 (Ubuntu stock). I tried your fix from svn but it didn't help.
    Hi duxa,

    It was a long shot but I thought I'd ask.

    Quote Originally Posted by duxa View Post
    I did this and made a call to my voice mail, the console output is attached. There are a lot of discards and padding.
    This is an interesting result. The buffer fill levels look great and during the entire session, your sound card would not appear to have overran or underran even once. However, for whatever reason, it looks like the phone and BT dongle system isn't producing audio packets quickly enough. All of the top output discard messages are undoubtedly happening because the input and output buffers for the BT dongle are managed in lock step, and the output buffer is not considered to have drained by one packet until an input packet is received. The audio pump needs to be better equipped to quickly diagnose this sort of problem, and I've got a few enhancements in mind to try to improve this.

    Anyway, I doubt this is a USB level problem, but just in case: After a session as above, does plain 'hciconfig' report an error count, or do you see any suspicious lines in /var/log/messages?

    Code:
    vision trunk # hciconfig
    hci0:	Type: USB
    	BD Address: 00:0A:94:02:5B:A0 ACL MTU: 384:8 SCO MTU: 64:8
    	UP RUNNING 
    	RX bytes:1811 acl:39 sco:0 events:89 errors:0
    	TX bytes:1232 acl:40 sco:0 commands:33 errors:0
    If this looks fine, please send me the output of 'hcidump' for a session. The dongle might be sending back some specific events that could shed light on why the audio packets are apparently bottlenecked.

    What kind of machine are you running this on?

    Sorry to take so long to get back, I was out traveling over the weekend.

  6. #56
    Newbie
    Join Date
    Oct 2008
    Posts
    7
    Hi Sam,

    thanks for your response and your patience, I highly appreciate this!

    Few bits of news; the microphone started working during call as well, I have no idea what did it. I did reboot the machine once and play with ALSA settings, but other than that..

    Also, I got two new BT dongles and tried them out, with little success:

    Celly BK3 (ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter):
    Sound was even worse than with the Prodige/Cambridge Silicon, it's like the signal was transposed to a really low frequency and there was a really weird echo.

    D-Link DBT-122 (ID 07d1:f101 D-Link System):
    Behaved exactly like Prodige - voice was annoyingly clicking 5-10 times/sec.

    If you'd like I could do some further testing with these, but for now I guess it's best to stick to the Prodige since it's got the same chip as your dongle.


    Quote Originally Posted by samr7 View Post
    Anyway, I doubt this is a USB level problem, but just in case: After a session as above, does plain 'hciconfig' report an error count, or do you see any suspicious lines in /var/log/messages?
    The error count was 0 and there was nothing in /var/log/messages during the session.


    Quote Originally Posted by samr7 View Post
    If this looks fine, please send me the output of 'hcidump' for a session. The dongle might be sending back some specific events that could shed light on why the audio packets are apparently bottlenecked.

    What kind of machine are you running this on?
    Dump is attached.

    The machine is a few months old, with Intel core 2 duo 2.66GHz (E8200) and 2GB DDR2 on an Asus P5K board. Top says python and hfpd processes take ~1% CPU during call (while the distortion can be heard).

  7. #57
    Newbie samr7's Avatar
    Join Date
    Mar 2006
    Posts
    42
    Quote Originally Posted by duxa View Post
    Few bits of news; the microphone started working during call as well, I have no idea what did it. I did reboot the machine once and play with ALSA settings, but other than that..
    Hi duxa,

    That's interesting.

    In the current code, the audio packets received from the phone are used as the sample clock for the phone. Following this model, audio captured from the PC microphone is only sent to the phone in the same proportion that audio packets are received from the phone. A bottleneck on audio packets coming from the phone will affect the other direction. The outbound audio sample clock could be separated from the input side using TIOCOUTQ to monitor the rate at which the kernel buffer on the outbound side is drained, but TIOCOUTQ is not working yet, and is only available on the most recent kernels, not including the one you're using. So, for now we use the input side to clock the entire endpoint.

    Previously I speculated that an input bottleneck on your phone was causing your problem. Since your sound card appears to be healthy, it should be the only remaining reason that the audio coming out of your speakers skips and is of generally poor quality. Determining the cause of this should be the highest priority. However, there might also be an output bottleneck. If you're feeling more adventurous, you can turn on more pump debugging by setting fill_debug = true the same place where you set loss_debug = true. This will generate a _lot_ more output, including what it thinks the buffer fill levels are each time the processing function is invoked, not just when it discards or pads some samples.

    Quote Originally Posted by duxa View Post
    Also, I got two new BT dongles and tried them out, with little success:

    Celly BK3 (ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter):
    Sound was even worse than with the Prodige/Cambridge Silicon, it's like the signal was transposed to a really low frequency and there was a really weird echo.
    I got an ISSC dongle in the mail a few days ago, and it worked perfectly the first time I tried it. It had ID 1131:1004, so it's not _exactly_ the same as the one you're using, but probably close enough. I don't know much about what's out there in the way of dongles yet, but the ISSC chips seem to have a characteristic default SCO MTU of 48:10, which neither the CSR, Broadcom, or ALPS chips have.

    Quote Originally Posted by duxa View Post
    D-Link DBT-122 (ID 07d1:f101 D-Link System):
    Behaved exactly like Prodige - voice was annoyingly clicking 5-10 times/sec.

    If you'd like I could do some further testing with these, but for now I guess it's best to stick to the Prodige since it's got the same chip as your dongle.

    The error count was 0 and there was nothing in /var/log/messages during the session.
    I'll guess that the D-Link dongle has a Broadcom BCM2045 chip, which you should be able to confirm with 'hciconfig -a'. Perhaps it would be better to concentrate on the others.

    Anyway, all of this suggests a software or driver issue rather than a firmware or hardware issue. So, absolutely, please stick with the CSR dongle.

    Quote Originally Posted by duxa View Post
    Dump is attached.

    The machine is a few months old, with Intel core 2 duo 2.66GHz (E8200) and 2GB DDR2 on an Asus P5K board. Top says python and hfpd processes take ~1% CPU during call (while the distortion can be heard).
    Where did you put the dump? I don't see an attachment and didn't get a PM.

    Thanks!

  8. #58
    Newbie
    Join Date
    Oct 2008
    Posts
    7
    The dump got lost somewhere.. Maybe I kept the message open too long after the upload. Here's try #2.
    Attached Files Attached Files

  9. #59
    Newbie samr7's Avatar
    Join Date
    Mar 2006
    Posts
    42
    Quote Originally Posted by duxa View Post
    The dump got lost somewhere.. Maybe I kept the message open too long after the upload. Here's try #2.
    Hi duxa,

    You're definitely receiving audio packets from the phone, there's no question about that. However, _nothing_ is being sent back, and this is very puzzling. I'm suspicious that hfpd may not be receiving these audio packets.

    Can you update your local view, rebuild, kill hfpd, run it under strace, and try to reproduce the problem? From the SVN view, I think it would be a command like:

    strace hfpd/hfpd -f

    Thanks.

    I just committed a few changes to try to verify basic assumptions, including non-contention over the SCO listener socket, and that the SCO voice setting of the HCI is suitable.

  10. #60
    Newbie
    Join Date
    Nov 2008
    Posts
    3
    Hi Sam,

    first of all, an awesome piece of code you've created! I've been looking for a HF application for quite some time...

    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...

    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.

    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.

    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.

    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.

    I'd appreciate any clues on this, since your app is really cool stuff !!

Similar Threads

  1. Instructions on getting FREE wireless internet from T-Mobile using GPRS
    By bankingdom in forum Wireless Communications
    Replies: 298
    Last Post: 08-16-2011, 03:37 PM
  2. Proper Bluetooth phone application (Paid or free)
    By f1racr in forum Wireless Communications
    Replies: 2
    Last Post: 06-28-2008, 10:41 PM
  3. Free Bluetooth Headset for people in L.A.
    By Rafster in forum Off Topic
    Replies: 0
    Last Post: 06-18-2008, 01:14 AM
  4. Replies: 0
    Last Post: 02-15-2007, 11:12 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •