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]

In reply to comment #50: Unfortunately, it does not seem to be that easy: The
PhoneApp just acquires a partial wake lock and/or a proximity wake lock (cf.
com.android.phone.PhoneApp). That's what Sipdroid has been doing (the partial 
wake
lock) and I have also been experimenting with the (undocumented) proximity wake 
lock
without success.

I am almost certain that the native PhoneApp continues working under these
circumstances because it does not rely on WiFi, whose throughput seems to be
negatively affected even if a wakelock is present.

Original comment by th...@google.ginkel.com on 14 May 2010 at 11:58

[GoogleCodeExporter]

This issue is confirmed on the HTC incredible also.

Original comment by stephen....@gmail.com on 17 May 2010 at 2:40

[GoogleCodeExporter]

Confirmed for my Verizon HTC Incredible as well. Horribly garbled (sounds as if
binary could speak) upon dimming.

Original comment by kra...@gmail.com on 24 May 2010 at 6:03

[GoogleCodeExporter]

I don't understand why a screen lock is held. A Wifi lock 
(http://developer.android.com/reference/android/net/wifi/WifiManager.WifiLock.ht
ml) 
seems to be more appropriate, as it should also prevent the Wi-Fi
Sleep Policy to interfere with calls.

Original comment by rhu...@gmail.com on 2 Jun 2010 at 8:15

[GoogleCodeExporter]

Issue 218 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 9 Jun 2010 at 7:45

[GoogleCodeExporter]

Issue 495 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 9 Jun 2010 at 7:45

[GoogleCodeExporter]

Issue 452 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 10 Jun 2010 at 3:34

[GoogleCodeExporter]

This issue also occurs on the Sprint EVO 4g

Original comment by errolun...@gmail.com on 12 Jun 2010 at 3:39

[GoogleCodeExporter]

HTC Legend also seems to be affected by this issue.

Original comment by ilya.sav...@gmail.com on 16 Jun 2010 at 7:25

[GoogleCodeExporter]

I'm using SIPDroid on the Droid Incredible and experiencing a similar issue. 
WiFi sleep policy is set to never, but instead of garbled sound it's just 
completely silent when the screen is off.

Original comment by kni...@gmail.com on 24 Jun 2010 at 11:03

[GoogleCodeExporter]

Same here on the EVO.  The received audio goes completely blank when the screen 
goes to sleep.  The screen goes to sleep erratically during calls: as quick as 
after 15 seconds to up to several minutes in some cases.  Waking up the screen 
restores the audio.  Link used is wifi, with always on policy.

Original comment by bernard....@gmail.com on 27 Jun 2010 at 8:59

[GoogleCodeExporter]

Issue 535 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 6 Jul 2010 at 10:14

[GoogleCodeExporter]

Same issue on the HTC Aria. Using WiFi as soon as the screen goes dark audio is 
garbled or non existent. Turing the display back on restores audio.

Original comment by kmcgrath...@gmail.com on 7 Jul 2010 at 3:54

[GoogleCodeExporter]

In the case of the HTC EVO 4G, turning the screen back on (and unlocking it) 
returns the user to the home screen, and there is then no way to get back to 
the call to hang up. The call does continue in the background, and it shows up 
in the notifications area, but pressing the notification item opens up 
Sipdroid's dialer screen, not the call. The only way to actually end the call 
is to forcibly terminate the Sipdroid process.

Original comment by mwhitl...@gmail.com on 7 Jul 2010 at 5:09

[GoogleCodeExporter]

so folks know, this appears to be a problem with most (all?) HTC phones, not 
with sipdroid. lots of people are observing that wifi suffers from enormous 
(though apparently not always 100%) packetloss when an HTC phone's screen turns 
off.

i guess commenter #47 also found this to be an android-wide issue. i personally 
have also had it disrupt mp3 streams. i guess the real trick is that very few 
apps rely on a constant connection to operate.

there are a couple bugs reported on the main android project page for this 
issue. this one is the highest-voted one i can find:

http://code.google.com/p/android/issues/detail?id=7421

everyone should go vote up that issue instead of this one so this gets 
attention from the android devs, or HTC, or whoever needs to fix it.

Original comment by steven.b...@gmail.com on 14 Jul 2010 at 4:55

[GoogleCodeExporter]

It's not exactly a problem but rather more of a feature.  To save power, the 
phone puts its WLAN interface in a low-power mode that causes the associated 
access point to queue packets, and then the phone's Wi-Fi wakes up about once a 
second and asks the AP to deliver any packets it has queued.  This means the 
radio can be powered down most of the time, but it also means the latency for 
receiving packets on the phone can be substantial.

There may be a way to prevent the WLAN interface from entering this power 
saving mode while Sipdroid is in a call.  That should be the avenue of 
investigation.  First off, does Sipdroid acquire a WifiLock from the 
WifiManager if it's routing a call over the WLAN interface?  If not, that might 
be the only fix needed to solve this problem.  If it does already acquire that 
lock, then further investigation will be necessary to find a way to keep the 
radio in "constantly awake mode" (CAM).

Original comment by mwhitl...@gmail.com on 14 Jul 2010 at 5:20

[GoogleCodeExporter]

from what I've read (of this and other issues, and the sipdroid source), it 
definitely acquires a wifi lock when a wifi call is in progress.

also from what I've read, there doesn't seem to be a "constantly awake lock", 
or no one knows of one.

how is it you know this detail about the wifi hardware on these devices? are 
you a developer of some kind? if what you say is true we should update the 
android issue to clarify the problem and desired state.

I contend this is still an issue regardless of it being a feature. it seems a 
wifi lock should always provide always-awake mode. it is hard for me to imagine 
an app which needs a wifi lock (indicating it needs to be connected 
uninterrupted), but can survive with batching packets every second (so high  
throughout over tcp, or fast responsiveness in general, is impossible).

Original comment by steven.b...@gmail.com on 14 Jul 2010 at 5:39

[GoogleCodeExporter]

Agreed that it should be possible to request CAM for the WLAN interface, but I 
don't think it should be part and parcel with the WifiLock.  Most applications, 
even those that want to maintain a Wi-Fi connection, don't need low latency or 
high throughput when the screen is off because that typically indicates that 
the user is not interacting with the phone.  Streaming media players and 
Internet telephony apps would be the most obvious exceptions.  How do apps like 
Last.fm Player and Pandora get around this Wi-Fi power-save issue on HTC phones?

I am a network software developer, but not for HTC.  It's pretty obvious that 
the phone is putting the WLAN interface in Power Save Polling (PSP) mode when 
the screen turns off.  As a demonstration of this, try starting up "ping" to 
your phone's IP address, and toggle the screen on and off.  You don't even have 
to unlock the lock screen.  When the screen is on, your pings will have 
relatively quick round-trip times.  The moment the screen turns off, your RTTs 
will jump up to approximately 1000 milliseconds.  Dead giveaway that PSP mode 
is in effect.

Original comment by mwhitl...@gmail.com on 14 Jul 2010 at 5:48

[GoogleCodeExporter]

Well, AFAICS even Google Listen is suffering from the problem (when you quickly 
turn off the screen before it has had a chance to do any significant 
pre-buffering). I think what kills the VoIP connection is the terrible latency 
and spiked data transfer rather than the reduced bandwidth in PSP mode. This 
may be why you usually do not notice these issues for streaming apps that can 
level out the spiking data transfer.

Original comment by th...@google.ginkel.com on 14 Jul 2010 at 5:57

[GoogleCodeExporter]

pandora and last.fm don't stream from live sources. this means they can have 
huge buffers (grooveshark, for instance, will buffer an entire song). the 
buffers in turn mean that these apps can afford to drop a connection without 
much problem (i.e., they can reconnect over 3g when wifi turns off or becomes 
unusable).

i have no idea if these apps use wifi locks (i have no idea if any are open 
source), but certainly none of them need to.

i still don't see a use for a wifi lock that doesn't provide CAM. the best edge 
case i can think of is ConnectBot or other ssh apps, but it's certainly not as 
critical as it is for SIP.

your analysis is certainly convincing that this PSP mode happens when the 
screen turns off. could you stick that in the android issue? :)

http://code.google.com/p/android/issues/detail?id=7421

Original comment by steven.b...@gmail.com on 14 Jul 2010 at 6:07

[GoogleCodeExporter]

This issue isn't related to Android issue 7421.  That issue is about the Wi-Fi 
Sleep Policy, which is an Android invention.  This is about the Wi-Fi Power 
Save Mode, which is a feature of the 802.11 protocol.

For what it's worth, there's an app in the Market that purports to be able to 
toggle the Power Save Mode of the Wi-Fi between CAM and PSP.  It's called 
"DROID/MS WifiPowerSavingOff."  It requires root privileges, though, and I 
don't know whether its change would "stick," since the HTC phones seem to 
toggle the WLAN's Power Save Mode at every screen power state transition.

Original comment by mwhitl...@gmail.com on 14 Jul 2010 at 6:20

[GoogleCodeExporter]

i'm reasonably sure that 7421 *is* this same issue, just misattributed. i 
picked that one because it had the most votes of any issue that looked like 
this one.

i guess since the real cause is better-established now, it makes sense to make 
a new issue with a new name and description. it seems clear that PSP mode, and 
lack of control for it, is causing shenanigans.

i just tried that app. it requires a native utility (wlan_cu) that i don't 
have, and can't find a reference to.

Original comment by steven.b...@gmail.com on 14 Jul 2010 at 6:33

[GoogleCodeExporter]

i had another thought for a sucks-slightly-less solution:

could sipdroid buffer its incoming data, so as to at least smooth out the call 
quality in this and similar situations?

obviously, the added latency would sound like calling the moon, but maybe 
that's better than no audio, or draining the battery with the screen on.

come to think of it, wouldn't a SIP client already need to adaptively buffer 
its data? why exactly is this situation much different from calling china, in 
terms of managing the audio stream?

Original comment by steven.b...@gmail.com on 14 Jul 2010 at 7:45

[GoogleCodeExporter]

I think a better workaround than that is simply to keep the screen on while in 
a call.  Sipdroid could set the brightness to the lowest level and then restore 
the original brightness upon terminating the call.  Clearly the best solution 
is to change the Power Save Mode of the WLAN interface, but for that we may 
need some cooperation from HTC.  Holding the screen on at the lowest brightness 
is a workaround that can be implemented today.

Original comment by mwhitl...@gmail.com on 15 Jul 2010 at 4:59

[GoogleCodeExporter]

Sorry, but I have to chime in here. I do sincerely feel with you all who have 
such a "broken" phone, but I want you to remember that

a) not all phones behave like that, i.e. my Milestone hasn't got a hint of a 
problem when the screen turns off

b) what if you're on 3G?

So clearly it _must_ be an option to choose from, and AFAICR there is already 
the option to keep the screen on in Sipdroid. So - three things need to be done

1) continue to nag Google/HTC about fixing the WiFi sleep bug
2) on WiFi, when the "keep screen on" options is on: keep screen on, maybe set 
to lowest brightness, but more importantly: overlay the screen with an 
(invisible) fullscreen surface which prevents unwanted screen interaction on 
facial contact
3) on phones which work fine, and on 3G/2.5G: behave like the normal phone app, 
and use proximity sensor to turn the screen off during a call

Esp. 3 is important, because at least one bugs concerning this have been merged 
into this one. I find it _very_ impractical that every time I make or receive a 
call, the first thing I have to do is to manually hit the power button in order 
to turn the screen off and prevent my face/ear messing with the phone.

It shouldn't be very difficult to implement 3, and just not doing it _despite 
having an option to turn it off_ is just silly.

Original comment by seidler2...@googlemail.com on 15 Jul 2010 at 4:56

[GoogleCodeExporter]

i agree with using the proximity sensor when possible. i haven't yet ended a 
call with my face, but i do not want there to be a first time.

in the interests of bugging google/htc, i submitted this new issue against 
android:

http://code.google.com/p/android/issues/detail?id=9781

i think it details the PSP problem, its probable consequences and possible 
solutions pretty well.

everyone on this issue should go vote for android 9781. ideally vote for 
android 7421  as well ... the more attention this gets, the better.

Original comment by steven.b...@gmail.com on 15 Jul 2010 at 5:41

[GoogleCodeExporter]

Issue 564 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 22 Jul 2010 at 4:30

[GoogleCodeExporter]

i took another look at the "DROID/MS WifiPowerSavingOff" app. the tool it uses, 
wlan_cu, is a tool for the TI wifi chip found in the (original) droid, not the 
broadcom chip found in my nexus one.

the droid and droid x (and other OMAP-based phones) use this TI wifi chip. i 
haven't seen anyone with either of these phones report this problem yet. i have 
read that all or most HTC phones have the same broadcom chip. i have been 
thinking, based on the one-sided balance of hardware among people reporting 
this issue, that the broadcom chip is at fault, or at least will be the source 
of the solution.

the fact that there is a "power saving" mode to be disabled on the TI devices 
is interesting. i guess it might be a different power saving mode (APSD?), or 
the TI module's power saving might not interfere with SIP calls for some 
reason, or problems with these phones might be underreported for some other 
reason.

Original comment by steven.b...@gmail.com on 23 Jul 2010 at 11:15

[GoogleCodeExporter]

Issue 603 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 16 Aug 2010 at 11:22

[GoogleCodeExporter]

In my case, connecting the phone to an usb port or the AC adapter fixes the 
issue. Seems like the phone won't change in the PSP mode when it is connected 
to a power source. When making calls over wifi I'm at home, so this is not 
really great but acceptable in the meantime.

Original comment by ekre...@gmail.com on 17 Aug 2010 at 9:08

[GoogleCodeExporter]

Sipdroid-debug.apk in #47 worked for me to prevent phone silence when sleeping 
on an HTC ARIA with CM6/froyo A013. However, is there a debug based on a newer 
version of Sipdroid? Thanks!

Original comment by sckaplan@gmail.com on 19 Aug 2010 at 6:58

[GoogleCodeExporter]

Issue 606 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 20 Aug 2010 at 7:32

[GoogleCodeExporter]

Is this still being worked on? The screen-on-while-in-call tweak works, but is 
more of a kludge than an actual fix. Still no way to force the WiFi to NOT 
enter PSP mode? :(

Original comment by simonbro...@gmail.com on 6 Sep 2010 at 10:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Is issue268-android21-fix included in the last beta version? I cannot hear the 
dialogue partner when the display turns off on HTC Wildfire, Android 2.1.

Original comment by andma...@gmail.com on 6 Sep 2010 at 10:31

[GoogleCodeExporter]

"I don't understand why a screen lock is held. A Wifi lock 
(http://developer.android.com/reference/android/net/wifi/WifiManager.WifiLock.ht
ml) 
seems to be more appropriate, as it should also prevent the Wi-Fi
Sleep Policy to interfere with calls."

Seems logical. Or does a WiFi lock not prevent PSP mode, only working in the 
same way as the WiFi Sleep Policy?

Original comment by simonbro...@gmail.com on 6 Sep 2010 at 10:49

[GoogleCodeExporter]

Unfortunately, A WiFi lock does not prevent the activation of PSP mode.

Original comment by th...@google.ginkel.com on 6 Sep 2010 at 10:50

[GoogleCodeExporter]

That. Doesn't. Make. Any. Friggin. Sense. *bangs head on desk*

Original comment by simonbro...@gmail.com on 6 Sep 2010 at 10:54

[GoogleCodeExporter]

There has to be a way out of this. If the screen is locked, I can't hear 
anything (I'm using a Dell Streak). If I try to keep it on, I (sometimes) end 
the call with my face. It's very annoying.

Original comment by valileo....@gmail.com on 23 Sep 2010 at 8:14

[GoogleCodeExporter]

I just received Android 2.2.1 OTA update on my Nexus One and the proximity 
sensor does *NOT* seem to affect the WiFi behaviour any more!

This was tested using 3CXPhone (which would also trigger this same issue) 
because SipDroid 1.5.7 beta doesn't seem to dim the screen any more (workaround 
for this bug, I presume).

Can anyone else confirm?

Original comment by mactalla...@gmail.com on 28 Sep 2010 at 5:54

[GoogleCodeExporter]

That sounds interesting. Could you test with Sipdroid (just turn the screen off 
manually during the call)? :)

Original comment by simonbro...@gmail.com on 28 Sep 2010 at 6:27

[GoogleCodeExporter]

Okay, here are my somewhat confusing results:

Phone: Nexus One stock Android 2.2.1

SipDroid 1.5.7
--------------
Proximity sensor does not trigger even with Screen On disabled.  Cannot test.
Manually turn off the screen while in a call (power button): WiFi stutters.

3CXPhone 1.2.3
--------------
Proximity sensor no longer causes WiFi to stutter: yay!
Manually turn off the screen while in a call (power button): WiFi stutters.

SipDroid 1.5.5 (I tried downgrading)
--------------
Proximity sensor does not trigger?? But it used to at some version.
Proximity sensor does not trigger in 3CXPhone with SipDroid 1.5.5 installed?!? 
Something strange is going on.

It appears there is some behaviour difference between the proximity sensor 
turning off the screen vs. manually turning it off.  I cannot properly test 
SipDroid even by downgrading.  I don't know if this is an incompatibility 
between older SipDroids and 2.2.1 or if there's just something wonky going on 
with my phone.

@the devs: Does the current release prevent the use of the proximity sensor on 
the Nexus One even with Screen On is disabled?  If so, could I get a version 
without it to test?

Original comment by mactalla...@gmail.com on 28 Sep 2010 at 7:48

[GoogleCodeExporter]

Issue 666 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 29 Sep 2010 at 8:19

[GoogleCodeExporter]

So 3CXPhone probably doesn't turn off the screen when the proximity sensor is 
triggered. Is it possible you have an AMOLED screen and it's just turning it 
black?

Original comment by simonbro...@gmail.com on 29 Sep 2010 at 8:38

[GoogleCodeExporter]

Sorry for the noise everyone.  I compiled SipPhone and stripped out the special 
case for N1 to test the proximity sensor on it... and it still messes with the 
WiFi.  simonbroenner is right that 3CXPhone must have changed what they're 
doing and not actually be turning off the screen.  (With AMOLED I can't tell 
the difference between black and off).  It must have been the previous version 
of 3CXPhone that I last tested and upon finding an improvement attributed it to 
the OS upgrade instead.

There was hope.  Then that hope was popped like a baloon.

Original comment by mactalla...@gmail.com on 29 Sep 2010 at 11:58

[GoogleCodeExporter]

Same problem with HTC Wildfire.
Tested with SipDroid 1.5 & 1.5.7
"Screen on" functionality makes it OK, but we can only use loudspeaker (or we 
will accidentally hang up conversation)

Any news on this issue?

Original comment by barre.sa...@gmail.com on 5 Oct 2010 at 3:56

[GoogleCodeExporter]

Other syptoms with Sipdroid-1.6-pre4 on Wildfire Android 2.1:
With option "screen on" OFF:
When the screen gets off, sound stops and a few seconds after the screen gets 
on again.

Whole conversation remains hashed.

Original comment by barre.sa...@gmail.com on 9 Oct 2010 at 5:19

[GoogleCodeExporter]

I have an HTC Evo with the latest OTA update of Android 2.2 (as of early 
October) and am happy to help debug this issue if requested.  I'm a software 
developer so I can make intelligent bug reports.  Non-rooted phone though and 
don't want to root it.

Original comment by gordon.m...@gmail.com on 12 Oct 2010 at 1:47

[GoogleCodeExporter]

Issue 709 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 27 Oct 2010 at 1:11

[GoogleCodeExporter]

Issue 730 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 11 Nov 2010 at 11:21