#734 Huge lagtime / black screens on Motorola Citrus WX445

[Anonymous]

Originally created by: solvent...@gmail.com

What steps will reproduce the problem?
1. make a call or answer a call
2. there is no 2
3. there is no 3

What is the expected output? What do you see instead?
-

What version of the product are you using? On what operating system?
0.01-01 on Android 2.1

Please provide any additional information below.
upon answering a call w. cSipSimple, the screen will turn black (no controls, just the header/menu bar at the top  where the clock is) for 10-12 seconds.  During this time, audio is streaming in both directions (and is usually crackly).  but no controls are available.  Finally the call status screen will appear.  During the call there seems to be tremendous lag in pressing buttons e.g. sometimes you cannot press the "end call" button for 20-30 seconds. 

cpu of this phone is 528mhz, I have rooted the phone and made sure no background apps are running, installed setcpu and locked the freq. at 528 but it doesn't help.  This is a pure SIP-SIP call using either ulaw or g722, over wi-fi to a local asterisk pbx.

is this device capable of csipsimple? or is the cpu just too puny?

[Anonymous]

Originally posted by: solvent...@gmail.com

wanted to add that I also tried the latest nightly dev build (2/21/2011) and experienced the same issues.  I have since uninstalled that version, rebooted the phone and reinstalled v0.01-01

[Anonymous]

Originally posted by: r3gis...@gmail.com

I think that CPU speed should be enough.

My first development was on a G2 which is only 600mHz and CPU had far enough capacities to handle calls.

So there is some things that could be interesting to check.
* Testing with the last version ([r683]) : I've recently disabled -hard disable not only settings- all features that requires Floating Point support for ARMv6 devices (speex echo cancellation, iLBC codecs).
* Ensure audio frequency is set to 8kHz and force pcmu. By default as you have a 2.1 device it has set the frequency to 16kHz. On most devices that has android 2.x it's fine cause CPU speed can easily support resampling. But on low CPU devices it's a good idea to avoid resampling. Even if quality is worse without resampling if CPU can't manage it, better to disable it :)...

As for g722 the codec produce directly 16kHz. Even if in this case the sip stack does not resample in your current configuration, I think that the driver ask too much resources in this case. To say the truth I never tried with my htc g2 with the 16kHz codec (it was not supported yet when I developed on g2 ;) ).

* You could also try to reduce media quality. See ExpertSettingsMode (wiki page - about global settings) to activate expert mode so that you'll find the option in media settings to change the media quality (try to set it to 3 instead of 4).

Let me know how it goes it's interesting to see what should be "minimal" settings to get the app working with low CPU devices.

However, I have a fear. It's that it's not about the sip stack but about the audio driver of moto citrus. There is some weird audio driver implementation made by manufacturers sometimes. It leads to make impossible for third party application to use audio in "streaming mode". (Streaming mode is different from playing music and from telephony app that can use other ways to play audio which does not rely on the same thing a third party application that want to stream audio rely)

[Anonymous]

Originally posted by: solvent...@gmail.com

Thanks very much for your notes  & suggestions.  I have noticed some improvement in the recent nightly builds.  I am up to [r700] now and while its still very slow to navigate the UI, I'm at least able to complete calls etc.  There is still some kind of "leak" or something occurring because after a few hours, csipsimple usually becomes extrememly unresponsive and the entire phone needs to be powered off and then back on to get things running again.  I have adjusted my audio settings to 8khz, disabled g722 completely (using just u-law now).  Setting the media quality to 3 didn't seem to make any difference so I set it back to the default 4.   I think we may just be pushing the limits of this CPU.

[Anonymous]

Originally posted by: r3gis...@gmail.com

(No comment was entered for this change.)

Mergedinto: 200
Status: Duplicate