krunal09 / sample

Automatically exported from code.google.com/p/csipsimple
0 stars 0 forks source link

PSP Wifi mode : Sound becomes choppy/garbled when the phone goes to sleep in mid-call #71

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Initiate/answer a SIP call
2. Keep the call active until the screen goes blank after timeout
3. Try to talk

What is the expected output? What do you see instead?
Talking should be possible after the screen goes blank.
Instead, sound becomes garbled. Waking up the phone with power button makes it 
normal again.

What version of the product are you using? On what operating system?
"pre3" apk on HTC Desire (Android 2.1).

Please provide any additional information below.

I heard a rumor that due to an HTC specific bug(?) CPU lock is not sufficient 
to keep the hardware running at full speed, screen lock is needed as well. This 
may be completely wrong though.

There is a similar ticket in sipdroid:
http://code.google.com/p/sipdroid/issues/detail?id=268

Original issue reported on code.google.com by egcros...@gmail.com on 2 Jul 2010 at 9:25

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
> 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Thanks for the super-speedy reply!

Original comment by sca...@gmail.com on 31 Jan 2011 at 10:22