I am currently trying to figure out how to fix an annoying bug in Sipdroid [1], which seems to be triggered by a power management optimization in Android 2.1:
While a SIP (VoIP) call is in progress via WiFi, the data transfer becomes unreliable (and basically stalls) as soon as the display goes blank after the display timeout or proximity sensor has been triggered. As soon as the display comes back (by hitting the power button or releasing the proximity sensor) the data transfer reverts back to normal.
Currently, the only possible workaround seems to be to acquire a PowerManager.SCREEN_DIM_WAKE_LOCK for the duration of the call, which reliably prevents the issue from surfacing. Still, I think it would be beneficial to come up with a solution that allows the screen to become blank (if only for reducing battery consumption).
I already tried getting a WifiManager.WIFI_MODE_FULL to no avail.
Any hint how to sort this out is much appreciated!
> I am currently trying to figure out how to fix an annoying bug in > Sipdroid [1], which seems to be triggered by a power management > optimization in Android 2.1:
> While a SIP (VoIP) call is in progress via WiFi, the data transfer > becomes unreliable (and basically stalls) as soon as the display goes > blank after the display timeout or proximity sensor has been > triggered. As soon as the display comes back (by hitting the power > button or releasing the proximity sensor) the data transfer reverts > back to normal.
> Currently, the only possible workaround seems to be to acquire a > PowerManager.SCREEN_DIM_WAKE_LOCK for the duration of the call, which > reliably prevents the issue from surfacing. Still, I think it would be > beneficial to come up with a solution that allows the screen to become > blank (if only for reducing battery consumption).
In the meantime I thought about this issue and came to the conclusion that it may not be WiFi throttling, which is causing the trouble, but rather CPU scaling. In that case, my question would be what other apps, such as media players are doing to avoid being throttled by CPU scaling while the screen is turned off?
I have the exact same problem on a download manager app I am trying to
write. My service aquires PARTIAL_WAKE_LOCK, but when the screen is
blank wifi downloads still seem to come to a stand-still (on Nexus
One). If I instead acquire a FULL_WAKE_LOCK (or SCREEN_DIM) all is
fine. Obviously, these don't make any sense for a download-
manager... Also, everything is fine with 3G downloads (they keep
going in the background whether I have any wakelock or not).
Did you ever figure this problem out?
-Jack
On Apr 15, 10:49 am, Thilo-Alexander Ginkel <th...@ginkel.com> wrote:
> On Apr 11, 3:12 pm, Thilo-Alexander Ginkel <th...@ginkel.com> wrote:
> > I am currently trying to figure out how to fix an annoying bug in
> > Sipdroid [1], which seems to be triggered by a power management
> > optimization in Android 2.1:
> > While a SIP (VoIP) call is in progress via WiFi, the data transfer
> > becomes unreliable (and basically stalls) as soon as the display goes
> > blank after the display timeout or proximity sensor has been
> > triggered. As soon as the display comes back (by hitting the power
> > button or releasing the proximity sensor) the data transfer reverts
> > back to normal.
> > Currently, the only possible workaround seems to be to acquire a
> > PowerManager.SCREEN_DIM_WAKE_LOCK for the duration of the call, which
> > reliably prevents the issue from surfacing. Still, I think it would be
> > beneficial to come up with a solution that allows the screen to become
> > blank (if only for reducing battery consumption).
> In the meantime I thought about this issue and came to the conclusion
> that it may not be WiFi throttling, which is causing the trouble, but
> rather CPU scaling. In that case, my question would be what other
> apps, such as media players are doing to avoid being throttled by CPU
> scaling while the screen is turned off?
> Thanks,
> Thilo
-- You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
On May 4, 3:18 am, jdeslip <jdes...@gmail.com> wrote:
> I have the exact same problem on a download manager app I am trying to
> write. My service aquires PARTIAL_WAKE_LOCK, but when the screen is
> blank wifi downloads still seem to come to a stand-still (on Nexus
> One). If I instead acquire a FULL_WAKE_LOCK (or SCREEN_DIM) all is
> fine. Obviously, these don't make any sense for a download-
> manager... Also, everything is fine with 3G downloads (they keep
> going in the background whether I have any wakelock or not).
that's interesting and probably rules out my CPU scaling theory making
the WiFi throttling theory more likely again (generic CPU throttling
would IMHO also affect 3G downloads).
> Did you ever figure this problem out?
Unfortunately, not. I reported it to HTC as a bug, but have not head
anything back from them. AFAIK, the N1 is also affected, so it may
make sense to report this on the Android bug tracker.
My own analysis is currently stuck as HTC is denying access to the
Desire's kernel source and I think the root cause to this phenomenon
is somewhere on the kernel level (related to how the [non-]existence
of a wake lock interacts with the WiFi hardware driver). Well, I could
try using the N1 kernel source code...
Regards,
Thilo
-- You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
