Open GoogleCodeExporter opened 9 years ago
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
This issue is confirmed on the HTC incredible also.
Original comment by stephen....@gmail.com
on 17 May 2010 at 2:40
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
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
Issue 218 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 9 Jun 2010 at 7:45
Issue 495 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 9 Jun 2010 at 7:45
Issue 452 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 10 Jun 2010 at 3:34
This issue also occurs on the Sprint EVO 4g
Original comment by errolun...@gmail.com
on 12 Jun 2010 at 3:39
HTC Legend also seems to be affected by this issue.
Original comment by ilya.sav...@gmail.com
on 16 Jun 2010 at 7:25
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
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
Issue 535 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 6 Jul 2010 at 10:14
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Issue 564 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 22 Jul 2010 at 4:30
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
Issue 603 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 16 Aug 2010 at 11:22
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
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
Issue 606 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 20 Aug 2010 at 7:32
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
[deleted comment]
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
"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
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
That. Doesn't. Make. Any. Friggin. Sense. *bangs head on desk*
Original comment by simonbro...@gmail.com
on 6 Sep 2010 at 10:54
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
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
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
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
Issue 666 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 29 Sep 2010 at 8:19
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
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
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
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
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
Issue 709 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 27 Oct 2010 at 1:11
Issue 730 has been merged into this issue.
Original comment by pmerl...@googlemail.com
on 11 Nov 2010 at 11:21
Original issue reported on code.google.com by
ctros...@gmail.com
on 9 Jan 2010 at 10:23