Garbled incoming when screen locks on Nexus One

[GoogleCodeExporter]

NOTE: This form is only for reporting bugs. For problems, questions, or
comments, please visit:  http://groups.google.com/group/sipdroid-users
What steps will reproduce the problem?
1. Register with either Callcentric or Link2Voip, either directly or via
pbxes.org
2. Place a call to 1-425-296-4774+ (the local # version of GOOG 411... for
whatever reason the toll-free version does not show this issue)
3. Respond to the voice prompts in order to keep getting some incoming voice.
4. Don't touch the screen. Wait for it to lock.

What is the expected output? What do you see instead?
Expected output: Voice quality should continue sounding equally good during
the call.
Actual result: Once the screen locks, incoming audio becomes completely
garbled. If I press the unlock button then the audio snaps back to sounding
perfect. Once the screen fades it's garbled again.

What version of the product are you using? On what operating system?
Version 1.2.4 beta on Android 2.1, Google Nexus One

Which SIP server are you using? What happens with PBXes?
Callcentric or Link2VoIP. Same results directly or through PBXes.

Which type of network are you using?
Wi-fi

Please provide any additional information below.
If I keep my finger on the screen throughout the call to prevent it from
going into lock, the call quality remains good. No idea why this is happening.

Original issue reported on code.google.com by ctros...@gmail.com on 9 Jan 2010 at 10:23

[GoogleCodeExporter]

Just to add I have tried various tweaks. I tried deleting me APN to prevent the 
phone 
from switching to Fido EDGE; and I simultaneously tried disabling the option 
that drops 
wifi for mobile data when the screen is off. Neither made a difference. Every 
time the 
screen goes dark the audio garbles, and whenever I light the screen back up, 
the audio 
goes back to normal.

I really wish someone would comment here and let me know if they can reproduce 
this 
issue..

Original comment by ctros...@gmail.com on 11 Jan 2010 at 10:09

[GoogleCodeExporter]

I'm having the same issue as ctroster.

Difference in our set up:  I'm using sipsorcery SIP credentials which connect 
to gizmo5 
as the primary service and sipgate as the fallback.

Original comment by mauricio...@gmail.com on 12 Jan 2010 at 1:59

[GoogleCodeExporter]

Same issue, same setup except:
only wifi is enabled and using PBXes and simplesignal

Original comment by Kev.Higg...@gmail.com on 12 Jan 2010 at 3:14

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 12 Jan 2010 at 9:37

• Changed state: FutureRelease

[GoogleCodeExporter]

I can replicate this issue on my Nexus One with Sipdroid 1.2.4 and my Gizmo5 
account
over WiFi.  The issue of incoming voice becoming garbled upon screen dimming 
while
using Sipdroid occurs not just with 425.296.4774 but with any recorded prompts 
such
as my voicemail account.

At no time did the voice prompt at 425.296.4774 understand anything I was saying
which means my outgoing voice was garbled from call initiation even with the 
screen
still unlocked.  The prompt's incoming voice became garbled once my screen 
dimmed,
and when I unlocked the screen the prompt's incoming voice became clear again 
but it
still could not understand what I said which means my outgoing voice remained 
garbled.

Original comment by jlo...@gmail.com on 13 Jan 2010 at 9:14

[GoogleCodeExporter]

To be clear, I am initiating calls through a callback via the Google Voice 
website on
my Nexus One's browser.

Original comment by jlo...@gmail.com on 13 Jan 2010 at 9:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Interesting. I am unable to verify performance over 3G as I can only get EDGE 
on my
provider.

Let me add though: I tried conducting a test in speaker phone mode over Wifi 
with
SIPdroid (i.e I never put my face close enough to trigger the proximity 
sensor). The
screen still turns off after a short period of time *even if* I set Wifi sleep 
to
never *and* I set a longer screen timeout. It seems the screen turns off 
anyways.

I suppose that forcing the screen behaviour to stay on would "fix" the problem 
from
one standpoint. But it still begs the question: Why should sound quality 
degrade with
the screen off?

Original comment by ctros...@gmail.com on 13 Jan 2010 at 4:23

[GoogleCodeExporter]

I can verify that i aslo have the problem, I used sipdroid on nexus one over 
wifi and
my poivy.com account. Every time the screen would dimm, the sound would get 
garbled,
when i press the power button to wake the screen up, the sound quality returns 
to normal

Original comment by aehas...@gmail.com on 17 Jan 2010 at 4:57

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 18 Jan 2010 at 3:25

• Changed state: Fixed

[GoogleCodeExporter]

thanks for releasing 1.3

i downloaded and installed from the market

on the nexus one, when trying to go into settings, the app produce this error:  
"Sorry! 
The application Sipdroid (process org.sipdroid.sipua) has stopped unexpectedly. 

Please try again."

i uninstalled and downloaded again to confirm 

Original comment by mauricio...@gmail.com on 18 Jan 2010 at 3:48

[GoogleCodeExporter]

Same here. Same error on Nexus One when I download and try to open settings.

Also the download from here (rather than market) is unsuccessful because the 
file
name has no .apk extension.

Original comment by ctros...@gmail.com on 18 Jan 2010 at 4:03

[GoogleCodeExporter]

regarding comments 12 and 13, I saw that too when I first installed Sipdroid on 
the
Nexus One. However, I was able to close it and try again. Thereafter, no 
problems. 

The "stopped unexpectedly" issue was only seen the first time, not again.

However, I don't think your comments are in the correct place. This issue is 
related
to a different topic.

Original comment by davestec...@gmail.com on 18 Jan 2010 at 4:12

[GoogleCodeExporter]

thx for confirming ctroster

davestec - sorry if we're not up to speed with the project-ticket posting 
etiquette.  i 
know that in my case, i posted the force close issue here because i posted to 
this 
issue and was merely following up.  i saw that the new topic was posted only 
after i 
had already posted comment 12 here.  

i will post back here regarding issue 268 when able to run sipdroid again.

Original comment by mauricio...@gmail.com on 18 Jan 2010 at 4:28

[GoogleCodeExporter]

Issue *NOT* fixed in version 1.3.1. Audio still garbles on screen lock on Nexus 
One, 
under same circumstances as reported above.

Original comment by ctros...@gmail.com on 18 Jan 2010 at 6:10

[GoogleCodeExporter]

Confirming that this issue persists using version 1.3.1 on a nexus one.

Original comment by mauricio...@gmail.com on 18 Jan 2010 at 9:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Would you like to test attached apk? It keeps the screen dimmed on during a 
call.

Original comment by pmerl...@googlemail.com on 18 Jan 2010 at 10:31

• Changed state: Started

Attachments:

• Sipdroid.apk

[GoogleCodeExporter]

SIPDROID & NEXUS ONE - The Real Issue

I edited this post to provide more accurate information, after reading 
subsequent
comments and doing more testing.

I've done some testing and this is what I have determined...

Sipdoird only has the garbled audio when calling over Wi-Fi and it is caused by 
the
screen turning off. When pressing the top button to wake the screen, the audio
returns again until the screen turns off. This can be repeated indefinitely.

TESTING

First I set [Settings -> Wireless & Networks -> Wi-Fi Settings -> Advanced -> 
Wi-Fi
Sleep Policy = Never].

Then I set [Settings -> Sound & Display -> Screen Timeout = 30 minutes].

With the Wi-Fi turned off and making calls over 3G, the audio remains good, 
even when
the screen turns off.

With Wi-Fi turned on, the screen will turn off causing the garbled audio until 
the
top button is pressed to wake the screen.

Thanks for the excellent application. Keep up the good work!

Original comment by fluid.au...@gmail.com on 18 Jan 2010 at 10:38

[GoogleCodeExporter]

Yes we have established the audio problem happens over wi-fi. I can't test 3G 
because
I don't have it.

but the "real issue" hasn't been fully elucidated - *why* should turning off the
screen over wi-fi cause garbled audio? Therein lies the solution to the problem 
if
anyone can find it.

Original comment by ctros...@gmail.com on 18 Jan 2010 at 10:48

[GoogleCodeExporter]

Thank you pmerl.

Your attached Sipdrioid.apk worked! It keeps the screen from dimming during 
WiFi and
eliminates the audio issue.

Nice work! Will this be incorporated into the next build?

Original comment by fluid.au...@gmail.com on 18 Jan 2010 at 10:48

[GoogleCodeExporter]

fluid.automation is right.

the *apk attached to comment 19 keeps the screen from turning completely off - 
so the 
lost percentage remains in the 1-3 range.

thanks for following up and through pmerl.

Original comment by mauricio...@gmail.com on 18 Jan 2010 at 10:58

[GoogleCodeExporter]

Indeed the attachment worked for me too. And if I manually dim the screen it 
garbles
again.

So this could be a temporary stop-gap fix, perhaps a checkbox to toggle in 
advanced
settings. The *real* fix involves figuring out why it garbles when the screen 
dims.
But in the meantime this is good enough for starters!

Original comment by ctros...@gmail.com on 18 Jan 2010 at 11:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the fix.  I agree this is a stop-gap fix and that sorting out what 
is going on 
would be ideal.  But since that we can again make reliable calls, I'd prefer 
focus be 
placed on getting the compression option working again or even alternate codec 
support :-) and this put on hiatus.

Cheers.

Original comment by kro...@gmail.com on 19 Jan 2010 at 10:00

[GoogleCodeExporter]

I have tried both 1.3.2 (as linked in this thread) and 1.3.3 on my Nexus One 
with
Gizmo5 and callback through Google Voice over WiFi.

Incoming audio sounds clear, however outgoing audio from my mic to the phone I 
call
constantly cuts in/out and is unusable.  The screen stays on and the lost 
percentage
stays at or around 0.

Original comment by jlo...@gmail.com on 20 Jan 2010 at 12:01

[GoogleCodeExporter]

jlo...: your outgoing audio problem may be the same as I have been working on in
issue 69.  I submitted a patch for that problem in that issue, but the patch 
has not
yet been incorporated into the main code.

Original comment by jropal...@gmail.com on 20 Jan 2010 at 5:03

[GoogleCodeExporter]

How about changing RtpStreamReceiver thread priority to 
THREAD_PRIORITY_URGENT_AUDIO 
instead of THREAD_PRIORITY_AUDIO, which is what the RtpStreamSender uses?

Original comment by j...@google.com on 21 Jan 2010 at 12:00

[GoogleCodeExporter]

I applied the attached patch, but that didn't seem to affect anything. Gizmo5 
echo
service is still choppy on the N1 with screen off, but fine w/ screen on.

Original comment by j...@google.com on 21 Jan 2010 at 6:12

Attachments:

• threadprio.patch

[GoogleCodeExporter]

I am using the latest version on my Nexus One and the same issue remains. The 
audio 
becomes garbled when I turn off my screen.

Here is something interesting I have noticed regarding the Android 2.1 and 
Nexus One. 
I like to listen to lots of internet radios over wifi. I am at university and 
we have 
overlapping access points - so I can walk all over without losing signal. 
HOWEVER!!! If I keep the SCREEN OFF, the Nexus One glitches between switching 
from AP 
to AP and many times I arrive right next to the next AP and the nexus one has 
not 
connected to it giving me zero signal and the RADIO has stopped streaming. BUT 
if I 
walk around with the SCREEN ON!!! it never drops the signal and the connection 
to the 
next AP is seamless and my online radio keeps playing.

it is definitely having something to do with the Android 2.1 - Nexus one 
lowering the 
search aggressiveness for new AP and lowering the signal strength when screen 
is off. 

Original comment by kalinvas...@gmail.com on 28 Jan 2010 at 8:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have been messing with this all week and I think I have the best set up 
confirmed. 
If you have gizmo, sipgate are what ever and google voice number(never run the 
google 
voice app on your android) always always use the web site. Ok so you have a 
google 
voice number and your forwarding to your sip client. On your android with 
sipdroid 
set up and green lights ago. Go to the web an go to google voice web site on 
your 
phone go to settings make sure your sip client is chosen and saved. Go to inbox 
make 
a call area code and all, answer the forward do what ever you want. Than hang 
up but 
make sure to hit cancel in the web browser for google voice. and dont hit the 
back 
button just go home. This Is what ive learned.

1.Never run, register, are use the google voice app, If you have hard reset.
2.Google voice app seems to call you along with you sip client. aka garbling 
static 
3.Hit cancel on the web browser after every call. google voice dont stop call 
till 
you do and you can get errors. 

thats really it for me if you set it up that far you should know what I 
mean..Peace 
rock on android

Original comment by ih8...@gmail.com on 8 Feb 2010 at 8:19

[GoogleCodeExporter]

PS I did it all on my phone never used a computer.

Original comment by ih8...@gmail.com on 8 Feb 2010 at 8:21

[GoogleCodeExporter]

Is there any progress with the solution to this problem regarding the sipdroid 
authors, or Google engineers?

Original comment by staticf...@gmail.com on 20 Feb 2010 at 11:27

[GoogleCodeExporter]

The only way to plug the issue is to set the phone to not let the display go to 
sleep.

Original comment by nrinz...@gmail.com on 21 Mar 2010 at 8:17

[GoogleCodeExporter]

I've found this issue affects Fring too. And in programs where I do large file
transfers, the speed drops when I lock the screen (even though it still stays
connected to wifi). I don't know what it is about the Nexus One but it does 
something
invasive to wifi connections when the screen goes off. The challenge is, what, 
why,
and how to counteract it?

Original comment by ctros...@gmail.com on 21 Mar 2010 at 8:28

[GoogleCodeExporter]

Just got my new HTC Desire (also running Android 2.1) and am experiencing very
similar issues: As soon as the screen dims the incoming audio completely drops. 
When
I turn the screen back on the audio comes back.

I was not able to figure this out from the existing comments: Is there 
currently any
workaround built into Sipdroid, which prevents the screen from dimming on the 
N1?

Original comment by th...@google.ginkel.com on 10 Apr 2010 at 8:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Same Problem Here. 
HTC Desire

I can not even seem to find the attachment that pmerl posted that has a fix.
fluid.automation, can you share that attachment again? or pmerl ?
<<Sipdrioid.apk>>

thanks

Original comment by robinkou...@gmail.com on 10 Apr 2010 at 11:17

[GoogleCodeExporter]

Just to add: Now that I've run the same version of Sipdroid on both N1 and 
Milestone
I can see that they must've programmed it to leave the screen on if it detects a
Nexus One. On the Milestone the screen locks as normal and there is no garbled 
audio.

So it looks like Sipdroid needs to detect the HTC Desire and put it in the same
category. I wonder if the HTC Incredible and Legend (and eventually the HTC Evo 
4G)
all suffer from this issue too?

Original comment by ctros...@gmail.com on 10 Apr 2010 at 11:19

[GoogleCodeExporter]

It might be true what your saying @ctroster. Cause i also have Archos 5 
Internet Tablet 
and it also suffers from the same problem. 

Original comment by robinkou...@gmail.com on 10 Apr 2010 at 11:31

[GoogleCodeExporter]

Issue 417 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 10 Apr 2010 at 12:21

[GoogleCodeExporter]

@ctroster: Do you have a chance to upgrade your Milestone to Android 2.1 and 
test
whether this will trigger the bug on the Milestone? I would like to figure out
whether this issue is 2.1-specific (as opposed to HTC-specific).

Original comment by th...@google.ginkel.com on 10 Apr 2010 at 11:04

[GoogleCodeExporter]

It's a Canadian Milestone and can't be upgraded yet unless I want to try 
flashing a
Thai or Brazilian ROM. But I'll try whenever I get it, maybe in a few months.

Original comment by ctros...@gmail.com on 10 Apr 2010 at 11:06

[GoogleCodeExporter]

The attached diff against SVN HEAD solves the issue by activating the screen 
wake
lock on all devices based on Android 2.1 or later. Reflection needs to be used 
to
determine the release as the SDK_INT field is only available for API level 4 
and above.

The attached Sipdroid-debug.apk contains a compiled test version including this 
fix
(along with a version # change).

I just made another interesting observation regarding the root cause of this 
issue: I
used an FTP server on my phone to copy the test APK to it. As soon as the 
screen went
blank the throughput collapsed. So it seems very likely that Android 2.1 
throttles
the WiFi once the screen goes blank.

Original comment by th...@google.ginkel.com on 11 Apr 2010 at 10:53

Attachments:

• issue268-android21-fix.diff
• Sipdroid-debug.apk

[GoogleCodeExporter]

Its now working like a charm.
It has fixed the problem in my HTC DESIRE.

I did not expect the problem to be fixed so fast.
Good job
Keep up the good work

Thank you very much

Original comment by robinkou...@gmail.com on 11 Apr 2010 at 1:51

[GoogleCodeExporter]

Here's a potential fix:

1. Install the 'Night Clock' application, run it when you want to prevent the 
OS from 
sleeping.

2. Enable the option to always stay awake while charging in 'Settings' -> 
'Applications' -> 'Development' -> 'Stay Awake'. 

3. Enable the 'Wi-Fi' sleep policy to never sleep in 'Setetings' -> 'Wireless & 
Networks' -> 'Wi-Fi Settings' -> (menu) -> 'Advanced' -> 'Wi-Fi sleep policy' 
-> 
'Never'.

Ping your android to see if the ping's continue after the default screen lock 
timeout... it should keep alive. 

The phone battery would probably lose charge quicker, but hey, you can't expect 
to 
leave wi-fi on if you want it to keep alive all the time...

Original comment by david.he...@gmail.com on 8 May 2010 at 10:58

[GoogleCodeExporter]

This is due to frequency scaling on the CPU used when entering sleep mode. You 
should prevent it from 
sleeping and turn the screen off like the phone application does.

Original comment by kohe...@gmail.com on 12 May 2010 at 3:27