PDA

View Full Version : Looking for a specific program/piece of code


probonic
5th February 2008, 03:11 PM
Hi,

I am currently looking for a piece of software that will do a specific job, or possibly a better solution to what I am trying to do. Let me give you a little bit of background...

I have got an O2 XDA Mini S, and a Parrot hands-free kit that does not support the A2DP bluetooth profile (only the handsfree profile). I am currently using TomTom 6 on my XDA with a bluetooth GPS unit. Everything works really nicely together, except I cannot get instructions from TomTom through my parrot (which is ultimately my goal).

The only way I can see of getting the TT instructions through my Parrot is to make use of the programs floating about that allow you to turn on and off redirection of sound through bluetooth. The idea I had was that if there was a program about (or maybe even write something myself) that would be able to signal when the sound coming out of the XDA exceeded and then dropped back below a threshold level, and then somehow link that into the bluetooth redirection programs, I could basically have any sound that is produced go through the Parrot only when they occur (including obviously the TT instructions).

Does anybody have any ideas on this? Any help would be greatly appreciated.

Thanks.

Myrddin Wyllt
5th February 2008, 09:36 PM
Point UI, a UI wrapper, has a feature similar to what you're describing. It's used just to save battery power by turning on BT only when an incoming call is detected, and then killing BT after the call is ended. I don't know if it's open source, but you might want to head over to their forums and see if you can find out how they did it.

You probably also want to haunt any TomTom forum sites (if any even exist).

As a final option, look into Mortscripts (http://mort.sto-helit.de/index.php?module=news&action=view&entry=17). People have done amazing tricks with Mortscripts, and this might be just the ticket. Mort haunts these boards, and may pipe in with an "I can (or cannot) do that with Mortscript" too...

I have a question, though. What's wrong with using the Wizard's built-in speakers for getting directions?

probonic
6th February 2008, 01:29 AM
I have a question, though. What's wrong with using the Wizard's built-in speakers for getting directions?To be honest, it's not too bad through the speakers although if I have my radio on which I usually do, sometimes it can be a little bit hard to hear, and it would be nice to just have the radio mute while it gives me the directions.

It's more of a "want" than a "need" really.

Thanks very much for the info :)

probonic
6th February 2008, 01:41 AM
Point UI, a UI wrapper, has a feature similar to what you're describing. It's used just to save battery power by turning on BT only when an incoming call is detected, and then killing BT after the call is ended. I don't know if it's open source, but you might want to head over to their forums and see if you can find out how they did it.It is quite easy for programs to detect when you're in a call - MortScript, I presume, probably can detect that quite easily as it's an overall Windows feature and will probably have a readily available part in the API.

The problem is not with turning the bluetooth on and off, it's actually detecting when TomTom is giving an instruction. To be honest I think I'll look into MortScript and if that can't do it then I'll probably just give up.

Mort
6th February 2008, 08:54 AM
Detecting phone calls isn't that easy, and it's especially not easy to make a check in a simple procedural script language like MortScript (up to WM5, there's no way to check whether a call is active, you have to monitor all the time if a call is accepted or hung up).

Detecting sound output of another application is entirely impossible - at least for most applications. If the app opens the output channel only during output (which most don't because it takes valuable time and causes ugly "click" noises on some devices), one could maybe query the number of free output channels - but that would need a CPU hog monitoring all the time, or half of the message would be over until it's detected.

And even if that would work, there's simply no way to redirect output to a BT headset (except with A2DP). At least on most devices. Once there was a simple way to do that (you just had to open a virtual port, and as long as it's open, everything was redirected similar to the A2DP way nowadays), but most manufacturers didn't implement it, and nowadays it seems like no modern device supports it anymore. (Had it for test purposes in a MortPlayer beta, no user reported it works...)

So, to put it short: Currently it's impossble. Maybe WM8 might change that... (Few hope for WM7, it's proposed to have the same kernel as WM5 and WM6.x)