#328 Audio sometimes becomes garbled after screen blanks in a call

[Anonymous]

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

What steps will reproduce the problem?
1.  Receive a sip call
2.  Put phone to ear
3.  Speak

I don't think this is not a duplicate of issue #71
Wifi ping times remain low.  The kernel flags an audio
driver error at the instant the problem occurs.

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

What version of the product are you using? On what operating system?
Version 0.00-15 from the Android Market installed on
Motorola Droid with Cyanogen and SimplyStunning ROMS
and various kernels.

Please provide any additional information below.
Log files:
sip*.dmesg  =>  dmesg output during sip call
sip*.logcat =>  logcat output during sip call

Compare with:
verizon.dmesg
verizon.logcat   

The verizon (CDMA) call logs record a number of sleep/wake cycles due to my activating the proximity sensor on the phone repeatedly. sip.* records one such cycle where the audio driver fails.  sip2.* records two cycles, the first works properly, on the 2nd screen lock, the audio driver reports failure.

Note that WiFi ping times remained < 5ms at all times during wifi calls.
I did see longer pings between calls, when in Wi-Fi PSP mode.

Let me know if you need more info.  It seems to me like some wakelock is not being held which allows the audio to shutdown when the phone sleeps during a call.

Thanks!

[Anonymous]

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

Sorry about the null verizon.logcat file.  It's attached to this comment...

[Anonymous]

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

Ok thx for the report and the very well detailed logs (dmesg is a really good idea).
Two thought :
You could try one latest dev build available on download section. Worth to try since I've fixed something on some devices but symptoms were different so i have little hope that it will help.
Second thing maybe we could ask cyanogen. Regarding the driver error it is not managed by the application but by the os. Even in the case it was my app that does crappy things (I don't think so since on other devices it works), it would be good to report that to cyanogen and his team (most of custom rom are based on same audio drivers) at least for robustness of the os.

Maybe try first the last version and then we'll consider asking on Motorola hackers if they have no clue about this kind of crash.
Any way you can also use the workaround of issue 71.
(Settings >menu expert mode and then settings > user interface > keep awake while in call.)

[Anonymous]

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

Any improvement observed with 0.00-16 ? (Many things have been changed meanwhile so maybe something that help on this issue).

[Anonymous]

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

Hi Regis,

I do like the looks of the new version better, particularly the contacts,
etc.
Also, I think that echo cancellation was improved.  At least it seems so.
Can you confirm that?

However, the new version didn't work well for me.  I've reverted back to
0.15
Here's why:

1)  I have one number with google voice that rings the phone via the cell
network and sipgate roughly simultaneously.
With 0.15, I would just dismiss the cell call and pick up the free SIP
call.  However, with 0.16, the phone locks when I dismiss the cell call.
Then, I must unlock it, at which point, I must pull down the notification
toolbar to select the "on going" sip to and answer it.
Too much fiddling while the other party waiting for me to answer my phone.
Do you see how 0.16 might have caused this change?

2)  The UI configuration kludges for keeping the phone await during calls
have been removed from 0.16.  It seems that the phone simply stays awake.
Did you do this for all phones, or just troublesome ones like the Droid?

3)  Too often, after I finally manage to answer an incoming sip call, the
other party cannot hear me.

I'm willing to try another version if it can help to debug these issues.
This is, by far, the most usable sip client on Android.
Just let me know how I can help.

- brent

[Anonymous]

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

Yes setting for echo canceller has been changed.

For point 1 could you try :
http://nightlies.csipsimple.com/trunk/
([r422])

And also try to test with STUN + ICE enabled for point 3.

[Anonymous]

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

Sorry [r422] was broken
http://nightlies.csipsimple.com/trunk/CSipSimple-r427-trunk.apk

[r427] should be ok.

[Anonymous]

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

[r427] is an improvement.  Much less latency and better echo suppression.
But, the options for keeping the screen and cpu on when the proximity sensor
activates seem to have been removed.  I still need this to prevent for my
Droid.   Same problem as originally present.  After the proximity sensor has
triggered a couple times, the outgoing audio quits.

Would you consider adding these UI options back?
Is there some secret way to enable them in [r427]?

By the way, I did not uninstall CSipSimple v0.15 before upgrading to [r427].
Is the OK?

[Anonymous]

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

These option are still there :) There is a secret... options are still there for power users :).

See ExpertSettingMode wiki page.

As for the fact Droid need the PSP hack I'm pretty interested. If so it means that I should turn on the feature by default.
So could you use the Help > Record logs and Help > Stop & send log (it will send me a report with the device info I can use to automatically turn on the PSP hack )

You don't need to uninstall previous version with recent release (however if was a market version replaced by the dev version the app may use more space that actually needed, but not really important ;) ).

Status: Started

[Anonymous]

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

This issue was closed by revision [r604].

Status: Fixed