How bout Bluez Handsfree Service (BzHFS)? Linux Handsfree?
How bout Bluez Handsfree Service (BzHFS)? Linux Handsfree?
What will the goal of this project be? A stand-alone application? A library?
I guess the question I have is what will we be doing with the audio once we have it. What tells the program what to dial etc?
Just looking to see what the direction of this project is going to be?
I suppose I should also write some sort of basic frontend app so people can actually use (and test) it without writing their own frontend, but I gather most people building a Linux carpc here are writing their own frontends? I think it might be best to focus on making an easy API to integrate this into a frontend.
How would YOU like to see it work? I'm still open to suggestions. My frontend is all Java though, so I'd like it to be easy to use from any language (i.e. not just a C/C++ library).
Oh, and bluesqueak seems to be somebody's university project already. Bummer.
I agree that a background deamon is the best way to go. It'll be language unbiased. Great work! Just make sure to document it well so we can use it in our front-ends.
I too love the idea of a dameon, however, I was wondering about the use of java. Since a lot of us are using lower powered systems, perfermance is always an issue. Java adds some overhead that I'm not sure we would want.... This is only my 2 cents, since I'm not coding anything (yet) -- I will defer to your much appreciated efforts
I shouldn't read messages so quickly....
Your only refering to the frontend :rolleyes:
Yes, java for my frontend, the daemon will be written in C++.
My original idea was a c/c++ library, but nix that I guess :P Unless someone wants to create java bindings. (Or Ruby, or Python, etc)
So a daemon huh. I'd suggest using sockets over pipes (Unless that is what you meant), be it UNIX-sockets or tcp/udp.
Is this something that will be started by the front-end app, or will it be started as a system service? Is this something that has to be able to handle multiple apps trying to access it? Or will it be owned by the spawning app, possibly using stdin/stdout.
Will configuration be done before hand through a .conf file? Will the daemon simply start and wait for a controlling entity to tell it what to connect to. Will it just try to connect to any phone that happens to wander by?
Bluetooth has a scan mechanism, but I was noticing that when I had an active connection to a device and I was scanning, I had problems. However, I have a broadcom based dongle, so needless to say it's not 100% to spec nor 100% supported (I should probably look for a CSR dongle).
I suppose the daemon could have a list of devices to be on the lookout for and either periodically try to connect to them or periodically scan for them. Then once it does find a device either connect immediately, or notify any connected clients that a device has come into range and await further instruction.
Another possibility is instead of a daemon just have some utility apps that are spawned from a client. For example, a bluectl app that you send cmds via stdin and it replies via stdout. When it is time for audio, spawn bluesco with a bdaddr as a param, then it listens for a connection (Or establishes one) and sends any data it receives on stdin to the device and sends any data from the device to stdout. You would also have to call hcitool scan to get any nearby devices to know when to try and connect.
I can't find this project you were talking about for BlueSqueak....
I had come up with two ways for it to behave:
when nothing is connected, it will scan for devices that appear to be phones that support handsfree. Whenever one comes in range or goes out of range, it will send the list of nearby phones to the frontend.
Also, it listens for incoming connections. When you tell your phone to connect to your PC, it will connect as a handsfree kit. Scanning would still go on in the background, if this works (I haven't tried with my adapter).
The frontend can also tell the handsfree service to connect. It can send multiple bdaddr's, and that will be the priority. i.e.
CONNECT <myphone> <yourphone>
That means as soon as myphone is in range, it will connect to it. If myphone is not in range, but yourphone is, it will connect to yourphone. If myphone then comes in range, it will not disconnect. But then if yourphone is disconnected, it will connect to myphone.
The frontend can also say DISCONNECT, which will drop the connection and not try to initiate any more (but will still listen for incoming ones). Or you could say SWITCH <bdaddr1> <bdaddr2>, etc. to re-prioritize the list and reconnect to the highest priority one.
I know that sounds a little complicated, but I think I'm just not explaining it well. Simplest case, you don't send any CONNECT string, and just wait for somebody to click connect on their phone, like most headset earpieces. Or, if you only have one phone, use CONNECT <myphone> to auto-connect to your phone whenever it is within range and DISCONNECT to stop auto-connecting.
This is a little simpler (for the handsfree daemon). It constantly scans and reports in-range and out-of-range occurences to the frontend. The frontend can say CONNECT <bdaddr> for a single shot connection, when the connection dies (say the device goes out of rantge then comes back in) the frontend would have to re-issue the CONNECT to get it to reconnect.
It would also listen for incoming connections with #2, just like #1.
Ok here's something a little confusing... with my motorola V551 I can only connect to my pc when I have the hf "handsfree" service registered and am listening on that channel (6). With my wife's LG something-or-other I can only connect to my pc when I have the hfag "handsfree audio gateway" service registered and am listening on that channel (7). What gives? Which one is correct? Can anybody here with another brand of phone check what you get?
Here's how I'm checking:
- pair your phone up first
- run "sdptool add hf"
- run "sdptool browse local" to see what rfcomm channel it specifies
- run "rfcomm listen hci0 n" where n is that channel
- You will see "Waiting for connection on channel n"
- use your phone to try to connect to your pc as a headset
- If that channel works, you will see
Connection from 00:0A:28:89:4E:65 to /dev/rfcomm0
Press CTRL-C for hangup
- After a moment it will disconnect since nothing is there to reply to it.
- run "sdptool del 0xnnnnnn" where that is the service record you see with "sdptool browse local"
- run "sdptool add hfag" and then repeat the above steps to see if you can connect on that channel.
I'd like to figure out whether this daemon will have to listen on multiple channels, etc. Or whether I'm just doing something dumb.