I overlooked this last time I read the thread. I'm going to try these settings for my Defy & see if it solves the disconnect issue I'm having.
-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
[APP] GrooVe IP - Google Voice VoIP
- Thread starter snrb
- Start date
I overlooked this last time I read the thread. I'm going to try these settings for my Defy & see if it solves the disconnect issue I'm having.
Would try the Keep Screen Alive. Could be something on the device going into a power saving state.
I tried that previously. Same deal. It's weird. I also suspect something the phone is doing, like maybe disconnecting wifi occasionally for power saving. I'm hoping that an official Motorola Defy update to 2.3 happens someday, it would probably solve the problem. I've also done a lot of experimentation comparing the two phones on outgoing by recording myself on voicemail & then listening with a landline phone & the RAZR is far less choppy for outgoing voice regardless of all the settings I try on the Defy. Actually the RAZR has no choppiness/clippiness at all. I think mostly because the dual core processor just kicks butt.
I wish the RAZR was a cute & waterproof as the Defy though -- it is a HUGE phone. I suspect in 2 or so years there will be a RAZR that is only as tall & wide as the defy, but super thin. I'm drooling just thinking about it.
BTW, the reason I have both of these phones is because of their exceptional microphones. They put all other phone microphones on the market to shame, especially Samsung, who has NEVER made a phone with anything other than atrocious outgoing voice quality. I've been suckered by Samsung "features" three times now, NEVER AGAIN!
Edit:
This sort of hit me in the head while I was writing this post: you should be able to bypass the API, at least until it's better understood, with an auto-answering mode. Not only is it a useful/popular feature in general, but in this specific case, people who want to exclusively use headsets wouldn't lose a lot from being unable to decide about the answer button: might as well just answer it for them! You could even have a "bluetooth mode" that only auto answers when a headset is connected. Add in an option, within bluetooth mode, to make the hangup procedure more complicated (i.e. less prone to accident), and you'd have a bona fide capacity for answering calls with the phone still in one's pocket
My original post no longer seems nearly as interesting (having an auto answer mode that works before the main phone is triggered would definitely solve the problem), but I'm leaving it below in case you find the case relevant.
-----
-----
Hi, I have another usage observation (I'm not sure if it's a bug or not) which leads to a feature request for ignoring the first x seconds of ringing.
I set my google voice to forward not only to groove ip, but also to the ordinary phone number in case I don't have access to data. That way, I can choose which one to pick up.
When both are available, though, what happens is that groove ip starts ringing first, followed quickly by the ordinary phone ringer, and then after a second or so groove ip pops back up on top of it again.
Bluetooth headset: if I pick up during groove's first ringing, it works fine. However, if I pick up during the phone ringing or groove's second ringing, the sound inexplicably switches over to speakerphone (despite "bluetooth" still being enabled for both). I have to turn the bluetooth option off and back on in order to get the sound back into the bluetooth headset. (I have already tried all the suggested troubleshoots for speakerphone-rerouting, but none of them seem to solve this particular issue.)
I think the problem here is that either program, when faced with a hangup, causes sound to revert to speakerphone. Because google voice immediately terminates the other connection when you pick one up, the other app would then trigger speakerphone (unless you picked up in the very first stage where only one app was active).
So my feature request: an option for groove to ignore the first x seconds of ringing (only starting the call screen if they're still on after x seconds). That way, I am able to answer early via bluetooth without disruption from a hangup. (It would also be nice to have a minor sound notification that a call is incoming but being delayed; that way we could know that the data service is indeed active!) Since, currently, picking up a groove call via bluetooth is not possible, the opposite issue would not occur.
The feature could also be used for other things, say, to weed out unimportant calls when on vacation. (Though I admit it'd probably be more of a "troubleshooting" feature.)
Thanks for reading my very long expose! I wish google would set it up so that delayed forwarding was easier, but it's probably not to be!
This sort of hit me in the head while I was writing this post: you should be able to bypass the API, at least until it's better understood, with an auto-answering mode. Not only is it a useful/popular feature in general, but in this specific case, people who want to exclusively use headsets wouldn't lose a lot from being unable to decide about the answer button: might as well just answer it for them! You could even have a "bluetooth mode" that only auto answers when a headset is connected. Add in an option, within bluetooth mode, to make the hangup procedure more complicated (i.e. less prone to accident), and you'd have a bona fide capacity for answering calls with the phone still in one's pocket
My original post no longer seems nearly as interesting (having an auto answer mode that works before the main phone is triggered would definitely solve the problem), but I'm leaving it below in case you find the case relevant.
-----
-----
Hi, I have another usage observation (I'm not sure if it's a bug or not) which leads to a feature request for ignoring the first x seconds of ringing.
I set my google voice to forward not only to groove ip, but also to the ordinary phone number in case I don't have access to data. That way, I can choose which one to pick up.
When both are available, though, what happens is that groove ip starts ringing first, followed quickly by the ordinary phone ringer, and then after a second or so groove ip pops back up on top of it again.
Bluetooth headset: if I pick up during groove's first ringing, it works fine. However, if I pick up during the phone ringing or groove's second ringing, the sound inexplicably switches over to speakerphone (despite "bluetooth" still being enabled for both). I have to turn the bluetooth option off and back on in order to get the sound back into the bluetooth headset. (I have already tried all the suggested troubleshoots for speakerphone-rerouting, but none of them seem to solve this particular issue.)
I think the problem here is that either program, when faced with a hangup, causes sound to revert to speakerphone. Because google voice immediately terminates the other connection when you pick one up, the other app would then trigger speakerphone (unless you picked up in the very first stage where only one app was active).
So my feature request: an option for groove to ignore the first x seconds of ringing (only starting the call screen if they're still on after x seconds). That way, I am able to answer early via bluetooth without disruption from a hangup. (It would also be nice to have a minor sound notification that a call is incoming but being delayed; that way we could know that the data service is indeed active!) Since, currently, picking up a groove call via bluetooth is not possible, the opposite issue would not occur.
The feature could also be used for other things, say, to weed out unimportant calls when on vacation. (Though I admit it'd probably be more of a "troubleshooting" feature.)
Thanks for reading my very long expose! I wish google would set it up so that delayed forwarding was easier, but it's probably not to be!
Hi snrb!
I have access to two Intercepts, relatively recent, from Virgin Mobile USA. One has been rooted and loaded with CrappyKernel 1.5, and the other is stock. Both seem to work with audio in/out on the earpiece via this workaround, which might be something that can be put into a hack setting:
1. Dial or answer.
2. Turn on speakerphone explicitly. (It's "on" already by virtue of default audio routing, but the speaker indicator in GrooVe IP is not on. This turns the indicator green, and switches to the app's speakerphone volume setting.)
3. Turn off speakerphone explicitly.
The audio is now on the internal earpiece, and the mic does work. I suppose that it's the cycling of default audio routing -> speaker on -> speaker off that does the trick. Ugly, but it appears to work, and I'm available to test a hack setting for this if needed.
(Oh, and none of the existing troubleshooting settings are enabled.)
[edit: I do use a separate app to keep wifi alive, but Keep Screen On would probably work too. Obviously, I don't think this is related to audio routing, but figured I'd mention it for completeness.]
I have access to two Intercepts, relatively recent, from Virgin Mobile USA. One has been rooted and loaded with CrappyKernel 1.5, and the other is stock. Both seem to work with audio in/out on the earpiece via this workaround, which might be something that can be put into a hack setting:
1. Dial or answer.
2. Turn on speakerphone explicitly. (It's "on" already by virtue of default audio routing, but the speaker indicator in GrooVe IP is not on. This turns the indicator green, and switches to the app's speakerphone volume setting.)
3. Turn off speakerphone explicitly.
The audio is now on the internal earpiece, and the mic does work. I suppose that it's the cycling of default audio routing -> speaker on -> speaker off that does the trick. Ugly, but it appears to work, and I'm available to test a hack setting for this if needed.
(Oh, and none of the existing troubleshooting settings are enabled.)
[edit: I do use a separate app to keep wifi alive, but Keep Screen On would probably work too. Obviously, I don't think this is related to audio routing, but figured I'd mention it for completeness.]
I love the idea of an auto answer mode. I'm going to add that to the feature list, don't think it should be too difficult either to implement.
Edit:
This sort of hit me in the head while I was writing this post: you should be able to bypass the API, at least until it's better understood, with an auto-answering mode. Not only is it a useful/popular feature in general, but in this specific case, people who want to exclusively use headsets wouldn't lose a lot from being unable to decide about the answer button: might as well just answer it for them! You could even have a "bluetooth mode" that only auto answers when a headset is connected. Add in an option, within bluetooth mode, to make the hangup procedure more complicated (i.e. less prone to accident), and you'd have a bona fide capacity for answering calls with the phone still in one's pocket
My original post no longer seems nearly as interesting (having an auto answer mode that works before the main phone is triggered would definitely solve the problem), but I'm leaving it below in case you find the case relevant.
-----
-----
Hi, I have another usage observation (I'm not sure if it's a bug or not) which leads to a feature request for ignoring the first x seconds of ringing.
I set my google voice to forward not only to groove ip, but also to the ordinary phone number in case I don't have access to data. That way, I can choose which one to pick up.
When both are available, though, what happens is that groove ip starts ringing first, followed quickly by the ordinary phone ringer, and then after a second or so groove ip pops back up on top of it again.
Bluetooth headset: if I pick up during groove's first ringing, it works fine. However, if I pick up during the phone ringing or groove's second ringing, the sound inexplicably switches over to speakerphone (despite "bluetooth" still being enabled for both). I have to turn the bluetooth option off and back on in order to get the sound back into the bluetooth headset. (I have already tried all the suggested troubleshoots for speakerphone-rerouting, but none of them seem to solve this particular issue.)
I think the problem here is that either program, when faced with a hangup, causes sound to revert to speakerphone. Because google voice immediately terminates the other connection when you pick one up, the other app would then trigger speakerphone (unless you picked up in the very first stage where only one app was active).
So my feature request: an option for groove to ignore the first x seconds of ringing (only starting the call screen if they're still on after x seconds). That way, I am able to answer early via bluetooth without disruption from a hangup. (It would also be nice to have a minor sound notification that a call is incoming but being delayed; that way we could know that the data service is indeed active!) Since, currently, picking up a groove call via bluetooth is not possible, the opposite issue would not occur.
The feature could also be used for other things, say, to weed out unimportant calls when on vacation. (Though I admit it'd probably be more of a "troubleshooting" feature.)
Thanks for reading my very long expose! I wish google would set it up so that delayed forwarding was easier, but it's probably not to be!
Just so I understand. You toggle speaker phone on then off again manually and that fixes the audio routing even on the stock intercept? I can check for the device type in the code and just do that automatically. Please shoot me an email, think it will be easier to work this through and give you a beta over email. snrb.labs@gmail.com
Gah! No, it doesn't work on stock after all. (I personally use an Intercept with CrappyKernel, part of the xda-dev "Almost Stock ROM" package; my friend has stock, and misreported results to me.)
E-mailing with more detail, though, because it's still worth adding for those willing to swap out the kernel.
Got your email, thanks.
I don't really have a list of headsets. That will depend on the phone/tablet and what kind of support the manufacturer has implemented for apps (bluetooth support for apps is different than what the native dialer supports). Some manufacturers only support bluetooth for music apps.
The BT I use is motorola H17 with a galaxy tab 10.1
Just downloaded the app and it seems to be working fine.
The only downside is the button on the bluetooth headset to answer the call doesn't answer the call. Major inconvenience to have to pull out the tablet and hit answer in order to start talking.
Is that a limitation in the app itself or something to do with the bluetooth headset? or were you already answering that in your previous response?
If it is app-related, is it possible to make that work in the future?
thanks a bunch
Just downloaded the app and it seems to be working fine.
The only downside is the button on the bluetooth headset to answer the call doesn't answer the call. Major inconvenience to have to pull out the tablet and hit answer in order to start talking.
Is that a limitation in the app itself or something to do with the bluetooth headset? or were you already answering that in your previous response?
If it is app-related, is it possible to make that work in the future?
thanks a bunch
Just as a followup, I don't know what the heck you did with that last update, but the problem is now fixed without my having changed anything else on the Defy except installing your latest version. AMAZING!!!!!!
Just as a followup, I don't know what the heck you did with that last update, but the problem is now fixed without my having changed anything else on the Defy except installing your latest version. AMAZING!!!!!!
Glad it's working better for you.
msneon1980
Lurker
I have a Tmo Samsung Galaxy S (1st Gen) that I put Groove IP on yesterday. There is not data service on this phone, it's factory (no rooting) but I did not do a reset on it. It was my old phone I gave to my daughter. It seemed to work fine, would take incoming calls, but now today it's only doing outgoing, and the calls are fuzzy. If you call it from another number it rings, but nothing happens on the actual phone, it doesn't ring. What could I do to fix this? Any suggestions? Thanks in advance.
Also I noticed last night that Groove Ip will log itself out and have trouble logging back on, even though I have the WIFI set to stay on.
Also I noticed last night that Groove Ip will log itself out and have trouble logging back on, even though I have the WIFI set to stay on.
For the incoming call issue I'd suggest double checking your Google Voice account to ensure calls are still being forwarded to Google Chat. You may also want to try enabling one or both of the lock settings in GrooVe IP troubleshooting. Some devices, mostly HTC devices, still put the wifi into a power saving state even if you have it set to stay on. Also if you have any task killer or battery manager apps they could be interfering.
I have been using GrooveIP for a bit now and really enjoy it, thanks! I have a request though. I have a personal GV number and a business GV number and would like to be able to be logged in through GrooveIP to both at the same time. Extra points would be given for a hold function between the two if a call come in one while I am on the other.
Thanks
Thanks
Both are features we're actively working on. Hold will most likely be in the next update. If not that then for sure in the update after that. Supporting multiple sign ins may take a bit longer.
Great to hear! Keep up the good work. Are we talking weeks or months do you think on the multiple sign-ins?
Yup, in development. Close to complete.
I've been noticing something similar: sometimes, Groove IP just refuses to login until you manually exit and restart it (and then it logs in fine).
(As an addendum: this doesn't seem directly related to wifi or power saving mode. I've done extensive "sting operations" randomly calling into groove ip after the phone's been several hours in "deep sleep": it almost always picks up fine. It's just sometimes it decides not to log in no matter what - even after you've reawakened the phone and made sure the internet works - and only an app restart fixes it.)