Closed GoogleCodeExporter closed 9 years ago
Interesting link to sipdroid. Many thanks.
Ok has to be investigated. A quick fix could be to add an option that allow to
force the screen on while in communication, but I hope that there is a cleaner
way.
Original comment by r3gis...@gmail.com
on 9 Jul 2010 at 12:11
I hope too, primarily because unlocked screen means it's all too easy to
inadvertently initiate some actions with your ear ;-)
Original comment by egcros...@gmail.com
on 9 Jul 2010 at 2:34
After reading some recent comments in the aforementioned sipdroid ticket and my
own investigation I am convinced that (at least some models) switch wifi
adapter to "Power-Save Polling" ("PSP") mode
http://www.lesswatts.org/tips/wireless.php automatically and unconditionally at
the same moment when they "go to sleep" locking the screen due to either power
button press or timeout.
This can be proven if you run "ping -i 0.2 <address>" against your phone. As
the screen darkens, you will notice that ping responses are coming, roughly, in
bursts of five once a second. Obviously when there is significant data stream,
the AP is unable to hold the whole second-worth of data and only short snippets
of the RTP stream are coming through once a second. Thus choppy sound.
Now unfortunately android's official API does not have anything to control this
behavior. Famous WifiLock is, according to the documentation, about quite a
different thing:
http://developer.android.com/reference/android/net/wifi/WifiManager.WifiLock.htm
l
Not that it helps, but maybe clears things out a bit...
Original comment by egcros...@gmail.com
on 15 Jul 2010 at 4:59
Really interesting comment ! Many thanks for the investigation.
Just a precision, to precise how csipsimple handle wifi while there is an
ongoing call.
There is of course a wifi lock that is asked by csipsimple, but there is also
something that try to set the wifi sleep policy to never sleep :
Settings.System.putInt(ctntResolver, Settings.System.WIFI_SLEEP_POLICY,
Settings.System.WIFI_SLEEP_POLICY_NEVER);
http://developer.android.com/intl/fr/reference/android/provider/Settings.System.
html#WIFI_SLEEP_POLICY_NEVER
On my device (N1 Froyo), it seems to work as expected since I never get choppy
sound. But, as you said, it's possible that on other devices such as HTC
Desire, wifi goes in a sleep mode state or this PSP mode.
What is possible too is that on the N1, setting wifi sleep policy to never also
prevent the PSP mode you described and that on Desire it only prevent wifi to
be disconnected.
So, if this is the cause of the choppy sound, my only solution is to add an
option to allow "Force screen on while in a WIFI SIP call".
Fortunately, I have also planned a visual locker in addition of the proximity
sensor.
I don't know if you ever seen that, but on the HTC G1 and G2, that had no
proximity sensor, after a timeout, a lock screen was displayed and you had to
double tap on it to unlock.
I think I will also implement that. So even with unlocked screen, the interface
will prevent you to initiate some unwanted actions.
Original comment by r3gis...@gmail.com
on 15 Jul 2010 at 8:40
As to WIFI_SLEEP_POLICY, it looks like it manages the same aspect of the system
behaviour as the WifiLock:
"The policy for deciding when Wi-Fi should go to sleep (which will in turn
switch to using the mobile data as an Internet connection)."
I.e. switch to PSP mode is made if the adapter is *not* sleeping. "Going to
sleep" means turning it off altogether and switching to mobile data connection.
What you suggest sounds as a good enough solution to me. I think that you could
introduce an option "Keep awake while on call" and if it is set, acquire
(SCREEN_DIM_WAKE_LOCK|ON_AFTER_RELEASE) powermanager lock for the duration of
the call. If you do, I'd be happy to test. Thanks!
Original comment by egcros...@gmail.com
on 15 Jul 2010 at 9:10
Ok. I understand.
Just for reference associated android issue :
http://code.google.com/p/android/issues/detail?id=9781
Seems sipdroid and frings also had implemented something that lock the screen
as you proposed.
Original comment by r3gis...@gmail.com
on 17 Jul 2010 at 9:25
Latest build
http://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-01.
apk
(Should uninstall previously installed version of csipsimple before installing
this one)
It add the keep awake while in call option. Not yet the visual locker, but
that's the next step :)
Btw, there is still something bad : I can't prevent the user from pushing the
power button that force the device to go in sleep mode and consequently
activating PSP mode.
P.S. : I'm able to reproduce with my nexus one in fact. But strangely on my
device the choppy sound is only in one way. PSP mode seems to affect only for
RX and not TX...
Original comment by r3gis...@gmail.com
on 17 Jul 2010 at 4:56
> CSipSimple_0.00-12-01.apk
Works for me as prescribed. Thanks!
> I can't prevent the user from pushing the power button
I would not bother about it. "Just don't do it!"
> I'm able to reproduce with my nexus one in fact.
> But strangely on my device the choppy sound is only in one way.
> PSP mode seems to affect only for RX and not TX...
Fascinating! I think the explanation may be simple: radio is turned on every
time when there is something to send, but to receive, it just polls once a
second.
I was wondering why "internet radio" streaming is not affected. I have no
proven theories; my first hypothesis was that as streaming is (often) done over
tcp, tcp flow control kicks in and prevents overflow of the buffers on the AP.
Then when I read your comment I thought that maybe it's the upstream packets
that keep the adapter awake, and if you are silent and VAD is active, there are
no upsteam RTP packets. In case of tcp, ACKs could play the role of such waking
upstream packets. However, it it was true, then you could try talking
constantly and then choppy incoming sound would have become normal. This is not
happening in my tests, so no such luck...
Thanks again!
Original comment by egcros...@gmail.com
on 17 Jul 2010 at 6:07
Umm... Could it be that you are forgetting to release the wake_lock after the
call is over? I just noticed that when I left the phone lying on the desk after
a call, it stayed dimmed and did not go to sleep. Or is ON_AFTER_RELEASE not
working the way I understood from the documentation?..
Original comment by egcros...@gmail.com
on 18 Jul 2010 at 10:38
The code to released the screen lock is present. This function should also tear
down wifi lock and restore previous audio settings.
So unless, there is a bug that made we never pass in this function (or an audio
deadlock just before), it should be ok.
What I understand with the ON_AFTER_RELEASE flag is that it makes the time
before sleeping long after I release the screen lock.
I can try a build without the on_after_release if you want.
Original comment by r3gis...@gmail.com
on 18 Jul 2010 at 11:43
I took a look at the code, and the lock should be released all right.
However, when I have the app running *and* "Keep away while on call" option
checked, *and* have made at least one call, then from that time on the phone
does not go to sleep at all and stays in dimmed mode indefinitely. "Quit" from
the app menu does not cure it. But if I "Force quit" from Android Menu->Manage
applications, the sleep behavior returns to norm, i.e. after timeout the phone
first dims and then black out.
It looks rather strange to me. I think you may be able to verify my findings
yourself.
According to the documentation, ON_AFTER_RELEASE should *not* cause such
behavior, it should just restart the idle timeout timer. Maybe there is a bug
somewhere?
Original comment by egcros...@gmail.com
on 18 Jul 2010 at 12:02
You're right, I'll reproduce and debug it.
If something is wrong with the unsetAudio method, side effects can be really
annoying for the user (and the phone battery).
Original comment by r3gis...@gmail.com
on 18 Jul 2010 at 12:24
I'm not able to reproduce your issue on my phone.
But... I think that I know what is happening. I forgot to test if not already
locked before taking the lock (not only in UAReceiver but also in InCall UI).
I'll test to implement this check and provide a new build.
Original comment by r3gis...@gmail.com
on 18 Jul 2010 at 2:16
After installing 12-02, "staying awake forever" does not happen to me, at least
so far. (However, "audio player muted forever" from issue 85 still stands).
Original comment by egcros...@gmail.com
on 18 Jul 2010 at 6:36
Great, it cancels my question in issue 85. :D
And confirms my guess. I'll provide you a new version really soon, but sounds
really logic regarding logs and the documentation :)
Many thanks for all the time you spent testing and debugging !
Original comment by r3gis...@gmail.com
on 18 Jul 2010 at 6:48
Build 12-03 :
http://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-03.
apk
Will fix the streamSolo issue from issue 85 with your sip server I think.
It will also remove some theoricaly not well released wifi locks.
Original comment by r3gis...@gmail.com
on 18 Jul 2010 at 9:53
12-03 fixes both sleep and mute problems for me.
Thanks! I am a happy user :)
Original comment by egcros...@gmail.com
on 19 Jul 2010 at 4:12
Had something similar happen to me on HTC Hero with VillainRom 12 (android 2.1)
and Dev-12-32. During a call sound suddenly becomes all garbled and breaks up
but phone can not be revived. I press the power button to light up the screen
but phone is unresponsive. Once call is disconnected power button works again
and everything is back to normal.
Original comment by dcitele...@gmail.com
on 19 Sep 2010 at 8:56
Well, fixed, proximity sensor on n1 only add a locker overlay.
On other devices, should turn off screen
Original comment by r3gis...@gmail.com
on 20 Sep 2010 at 6:44
First off, just switched from Sipdroid yesterday, and I like your app a lot
better! Kudos.
I'm having the issue that the screen *does* not turn off on my HTC Desire, even
if I want it to. Im running the newest Cyanogen 6.1.1 (device still reported as
HTC Desire), which seems to fix the WiFi screen sleep problems: turning off the
screen by pressing the power button does not at all interrupt the ongoing call.
In another ticket I found a reference to an option in the UI settings screen,
which does not seem to be available on my install (latest marketplace). Do I
need to switch to nightlies?
Thanks!
Original comment by sca...@gmail.com
on 31 Jan 2011 at 9:56
No you don't need.
There is expert option for power users :)
Read this page : ExpertSettingMode
You'll be able to disable the option "keep awake while in call".
Indeed that's not need with CM builds cause they deactivate PSP behavior of the
wifi card.
And in CM7 I heard that it will not needed anymore for stable 2.3 cause I'll
use a new API that allow PSP behavior and full speed locks on it.
Original comment by r3gis...@gmail.com
on 31 Jan 2011 at 10:03
Thanks for the super-speedy reply!
Original comment by sca...@gmail.com
on 31 Jan 2011 at 10:22
Original issue reported on code.google.com by
egcros...@gmail.com
on 2 Jul 2010 at 9:25