Originally created by: egcros...@gmail.com
Originally owned by: r3gis...@gmail.com
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:
https://code.google.com/p/sipdroid/issues/detail?id=268
Tickets: #100
Tickets: #1069
Tickets: #276
Tickets: #328
Tickets: #449
Tickets: #458
Tickets: #488
Tickets: #49
Tickets: #86
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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.
Owner: r3gis.3R
Status: Accepted
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: egcros...@gmail.com
I hope too, primarily because unlocked screen means it's all too easy to inadvertently initiate some actions with your ear ;-)
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: egcros...@gmail.com
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.html
Not that it helps, but maybe clears things out a bit...
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: egcros...@gmail.com
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!
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
Ok. I understand.
Just for reference associated android issue :
https://code.google.com/p/android/issues/detail?id=9781
Seems sipdroid and frings also had implemented something that lock the screen as you proposed.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
Latest build
https://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...
Status: Started
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: egcros...@gmail.com
> 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!
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: egcros...@gmail.com
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?..
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: egcros...@gmail.com
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?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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).
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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.
Summary: PSP Wifi mode : Sound becomes choppy/garbled when the phone goes to sleep in mid-call
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: egcros...@gmail.com
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).
Related
Tickets: #85
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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 !
Related
Tickets: #85
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
Build 12-03 :
https://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.
Related
Tickets: #85
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: egcros...@gmail.com
12-03 fixes both sleep and mute problems for me.
Thanks! I am a happy user :)
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: dcitele...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
Well, fixed, proximity sensor on n1 only add a locker overlay.
On other devices, should turn off screen
Status: NextRelease
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: sca...@gmail.com
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!
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: sca...@gmail.com
Thanks for the super-speedy reply!