Thread: bluetooth woes

Hello, good work on your project, I know first hand how difficult bt application programming and debugging can be Just an FYI here, in the coming months my company may release it's bluetooth sdk under open source license and it will be available on SF (with BlueZ adaption layer among others). There's working handsfree/headset, irmcsync, streaming audio, DUN, and PIM management interface. You probably can use this for your project once it is released (all written in C though)... I'll repost if this should happen...

Originally Posted by cyberwizzard

I found the SF project page: http://sourceforge.net/projects/Bluehands/
Nicely done

Thanks! I was going to post the link once I had something somewhat working But everybody feel free to checkout the CVS source and poke around, everything up there *should* be working/tested, it's just missing some important files (that I'm still working on).

Originally Posted by cyberwizzard

I found out that my K750i has the same issue you had before: it 'hangs' for a bit before answering some commands and as the handsfree application has no form of buffering (whatsoevah), I keep locking up the setup sequence... Actually I'm sort of surprised the demo application tries to read the return code in the first place as it doesn't actually do anything with it... Well nuff ranting about that.

You mean the OK vs ERROR strings it returns? Well even if you don't care whether it says OK or ERROR, you should still use either of those strings to know when the phone has finished processing the command and is ready for the next one. I don't remember if the old handsfree app does that or not, but I thought it did.

Originally Posted by cyberwizzard

Hows the library coming along? Anything that sorta compiles and I can try to hook into with Java/JNI/Exec? Would be cool to start testing

I am getting very close. Life keeps getting in the way of hobbies so I haven't worked on it in a few weeks I know I've said this before, but hopefully in a few days...

Originally Posted by smeesseman

Hello, good work on your project, I know first hand how difficult bt application programming and debugging can be Just an FYI here, in the coming months my company may release it's bluetooth sdk under open source license and it will be available on SF (with BlueZ adaption layer among others). There's working handsfree/headset, irmcsync, streaming audio, DUN, and PIM management interface. You probably can use this for your project once it is released (all written in C though)... I'll repost if this should happen...

That would be terrific! I'll keep working on this in parallel, but it would be great to see what you guys come up with.

Hi everyone,

I have a very basic version packaged and uploaded here:
http://sourceforge.net/projects/bluehands/

It is not useful yet (no audio, just RFCOMM connect/disconnect) but I would really appreciate it if everyone could try it out and let me know how it behaves with your phone (if it does something weird, please include debug output). Try normal stuff (connecting, making sure it stays connected for a long period, disconnecting nicely) as well as abusing it a bit (hit cancel in the middle of a connection or a negotiation, etc.) Oh and when reporting back, let me know the make/model of the phone as well as the BT adapter. And if you're really feeling ambitious, what version of bluez you've got (try hcitool --help, it should say in the first line... I *think* that's the bluez version).

I'm sorry the file release is so large, that is because it is compiled in debug mode. It's not bloat, it will shrink, don't worry

Awesome! As soon as I can I'll download it and test it with my SE K750i and a Motorola V600 :-)

Any chance I can tap into the audio feed anytime soon? I was playing with some echo cancellation algoritms

Tested it - no dice...

First off: the java command refers to jbluehands in a different directory while the release uses the same dir for all files.

Second: I'm running 64-bit Gentoo, I tried putting the *.so files in /lib32 and /lib64 but I keep ending up the same way:

Code:

localhost bluehands_0.01 # java -cp LookMaNoHands.jar:jbluehands.jar:. org.bluehands.lookMaNoHands.Main
Warning: Cannot convert string "-b&h-luxi sans-medium-r-normal--*-140-*-*-p-*-iso8859-1" to type FontStruct
Exception in thread "main" java.lang.UnsatisfiedLinkError: no jbluehands in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
        at java.lang.Runtime.loadLibrary0(Runtime.java:822)
        at java.lang.System.loadLibrary(System.java:993)
        at org.bluehands.Bluehands.getInstance(Bluehands.java:42)
        at org.bluehands.lookMaNoHands.DisconnectedPanel.<init>(DisconnectedPanel.java:75)
        at org.bluehands.lookMaNoHands.MainWindow.getDisconnectedPanel(MainWindow.java:162)
        at org.bluehands.lookMaNoHands.MainWindow.getCurrentPagePanel(MainWindow.java:154)
        at org.bluehands.lookMaNoHands.MainWindow.getMainContentPanel(MainWindow.java:118)
        at org.bluehands.lookMaNoHands.MainWindow.<init>(MainWindow.java:69)
        at org.bluehands.lookMaNoHands.Main.main(Main.java:31)

Could be a problem with the 64-bit thing but even putting it in the 32-bit library directory didn't help. (Yes, I ran ldconfig)

Originally Posted by cyberwizzard

Tested it - no dice...

First off: the java command refers to jbluehands in a different directory while the release uses the same dir for all files.

Second: I'm running 64-bit Gentoo, I tried putting the *.so files in /lib32 and /lib64 but I keep ending up the same way:

Code:

localhost bluehands_0.01 # java -cp LookMaNoHands.jar:jbluehands.jar:. org.bluehands.lookMaNoHands.Main
Warning: Cannot convert string "-b&h-luxi sans-medium-r-normal--*-140-*-*-p-*-iso8859-1" to type FontStruct
Exception in thread "main" java.lang.UnsatisfiedLinkError: no jbluehands in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
        at java.lang.Runtime.loadLibrary0(Runtime.java:822)
        at java.lang.System.loadLibrary(System.java:993)
        at org.bluehands.Bluehands.getInstance(Bluehands.java:42)
        at org.bluehands.lookMaNoHands.DisconnectedPanel.<init>(DisconnectedPanel.java:75)
        at org.bluehands.lookMaNoHands.MainWindow.getDisconnectedPanel(MainWindow.java:162)
        at org.bluehands.lookMaNoHands.MainWindow.getCurrentPagePanel(MainWindow.java:154)
        at org.bluehands.lookMaNoHands.MainWindow.getMainContentPanel(MainWindow.java:118)
        at org.bluehands.lookMaNoHands.MainWindow.<init>(MainWindow.java:69)
        at org.bluehands.lookMaNoHands.Main.main(Main.java:31)

Could be a problem with the 64-bit thing but even putting it in the 32-bit library directory didn't help. (Yes, I ran ldconfig)

Ah. Well I think you can safely ignore the font warning. As for the library path, I haven't written an installer or anything, so after compiling the libs (or downloading) you need to move them someplace appropriate... I've been using /usr/lib, so that's where the path is hardcoded in the runLookMaNoHands script. I believe you would add -Djava.library.path=/lib32 or something (off the top of my head)

Originally Posted by cyberwizzard

Any chance I can tap into the audio feed anytime soon? I was playing with some echo cancellation algoritms

After I finish the connection management (right now I'm working on auto-detecting what channel to connect to and listen on) then I will go for the audio. I'm still trying to figure out how to output the audio... I'm thinking JACK maybe. I don't want to just play it straight to alsa or whatever, because I want people to be able to route it to the speakers they want, add echo cancellation, mix it with their music for cross-fading, etc. Do you have any other output ideas?

I'm stoked that you're trying out some EC. I have a few links to some papers about EC algorithms on my work computer, I'll post them when I'm back at work (monday).

How about handling the audio via a pipe. Then the end user can process the audio as they see fit. (And since it is an FD, they can sit on it and wait for data to arrive).

Another option would be to provide a base class that the user needs to implement to handle read/write of audio data, then leave the responsibility of thread safety and actual implementation to the end user :P You couls always provide some generic interfaces, such as ALSA/JACK/OpenAL/etc. for the lazy.

Of course this is thinking from the c++ side of things, dunno about java.

--Zims

Hey I like the idea of extending a class - that would be the way to do it in Java. How would that work in plain C (not ++)? I want to make my API compatible with both C and C++. For right now my whole public API is just plain functions that should be usable from both, but I plan to object-orient-ify it a bit, and provide 2 parallel APIs like JNI. So for example, you could have:
phone->GetName (); // C++
or Phone_GetName (phone); // C

So for right now I'm thinking of making everybody register a callback that will get audio data as it comes in. And I'd like to provide some generic "lazy" callbacks you can use if you just want some sound without anything fancy. Maybe later on I can OO-ify it if I can think of a compelling reason.

Here are the EC links I promised:
http://www.embeddedstar.com/articles...0030720-7.html
http://en.wikipedia.org/wiki/Least_mean_squares
http://web.archive.org/web/200605040...aft-aec-03.txt
(that last one is via the wayback machine, since it has been removed). But it gives actual source code! So it should be useful.