Workaround SetCPU

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Make a call. 
2. Talk normally without raising your voice. 
3. Raise your voice all of a sudden. 

What is the expected output? What do you see instead?
Expect outgoing audio stream. As soon as I start talking loud to the microphone 
audio cuts out and all the other side can hear is a buzz. 

What version of the product are you using? On what operating system?
016, Motorola Droid 2.2.1

Please provide any additional information below.
This happens on 3G and WiFi. 

Original issue reported on code.google.com by gmgem...@gmail.com on 19 Jan 2011 at 6:54

[GoogleCodeExporter]

What codec is used for communication? (press the little (i) button in call 
screen).

That's strange I never experiment this kind of problem, and sometimes using 
amplification I raise a lot media stream.
Could be something due to moto droid mic
Or some bug in one of pjsip codecs.
Could also be something with other side / or server (if it transcode media). 

So some interesting tests you could do :

* Try to increase micro amplification in ExpertSettingMode (see wiki page in 
general settings section to activate this mode if not already done), and in 
Media > mic amplification. And see if you observe that even if you speak 
normally. (As amplification is done just after acquiring from micro, it will 
help to determine if it's something with moto micro).

* Try to use another sip provider (if you have any ;), if the other side you 
call is a sip (true IP) client, you can open a free ekiga account for example.

* Try to force another codec (must be supported by your sip provider or remote 
party if provider does not transcode). You can change codecs in settings > 
codecs (long press to disable one codec).

* Try to disable CSipSimple voice auto detection and/or echo cancellation.

Original comment by r3gis...@gmail.com on 19 Jan 2011 at 7:42

[GoogleCodeExporter]

PCMU 8khz is used. This is the only codec Broadvoice supports. I doubt moto 
droid's microphone is faulty or problem is on the other side or on the server 
since I can make voip calls with Broadvoice app called Airdroid, which is based 
on an old version of sipdroid, without any issues. Maybe it's a bug within 
pjsip itself. I will do some tests later today and let you know the outcome. 

Original comment by gmgem...@gmail.com on 19 Jan 2011 at 6:47

[GoogleCodeExporter]

I've done lots of testing. Disabled voice auto detection and echo cancellation. 
Tried increasing and decreasing micro amplification. Tested with different 
clock rates. Tested with different codecs disabled. Nothing seems to help. How 
often pjsip gets updated by it's developers? I hope the problem disappears with 
future software release. 

Original comment by gmgem...@gmail.com on 20 Jan 2011 at 7:59

[GoogleCodeExporter]

A release is planned in 7 day and another in 2 weeks. But I don't think this is 
an issue they know about.

When you increase and decrease micro amplification it doesn't change the sound 
level when you observe the bug? If so it can help having an idea where the 
problem can be. (if it does not impact the sound level it means that server and 
lower pjsip stack are ok). So problem can involve whether the my android port 
of the audio device or the way I open the device to read in. 
Some manufacturer do strange implementation of audio devices API which 
potentially break things. In this case could be interesting to test the audio 
troubleshooting workaround (see the FAQ wiki page in 
Audio_routing_troubleshooting section : 
http://code.google.com/p/csipsimple/wiki/FAQ?wl=en#Audio_routing_troubleshooting
 ).

In fact, some manufacturer consider applications should open the audio layer 
using IN_CALL mode while other prefer NORMAL mode cause IN_CALL mode plug 
directly (or partially) the micro/earpiece with the GSM chipset. By default, 
following advises from somebody that implement driver for some manufacturer I 
choose NORMAL mode. But maybe on other devices it could be better to use 
IN_CALL mode. (so the Use MODE api option).

Original comment by r3gis...@gmail.com on 20 Jan 2011 at 9:37

[GoogleCodeExporter]

The only setting that affects the way the bug occurs is when I change clock 
frequency. When I have clock ratio set to 32 kHz audio is good for about 40 to 
50 seconds. Sound level doesn't trigger the bug during this time. Any change in 
sound level after this time results in a buzz and no sound shortly after. If I 
set clock ratio to 8kHz the bug develops much faster 5 to 10 seconds. Sound is 
very distorted before it fails to the point that people can't understand my 
words. If I set clock ratio to 16 kHz it takes 20 to 30 seconds before bug 
develops. In 44 kHz mode I can't get audio at all or it fails shortly after 
starting a call. I must say bug behavior is very erratic. I haven't had a time 
to experiment with audio troubleshooting workaround, will do it later today and 
let you know. 

Original comment by gmgem...@gmail.com on 20 Jan 2011 at 6:16

[GoogleCodeExporter]

I've tried every combination of settings for audio workaround and can tell that 
these settings have no affect on a bug behavior. Also after installing dev 
version audio issue appears much sooner after about 10 seconds in 32 kHz mode. 
I hope you can pinpoint the problem based on an information I gave you and fix 
the issue in some future release. 

Original comment by gmgem...@gmail.com on 21 Jan 2011 at 5:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This issue seems directly related to my issue 
http://code.google.com/p/csipsimple/issues/detail?id=569#c5 which was closed as 
solved. I have a little more info and a suggestion. When I toggle speakerphone 
people can hear me again. When I use routing api and mode audio api and I press 
speakerphone and leave it on sound comes out earpiece. 

   If you could add a setting to call and answer using speakerphone automatically we may be able to solve this issue using those settings and not have to leave screen on during calls :-). It may not solve the issue but I believe its worth a shot. What do you think?  
   To the original poster. Try to toggle speakerphone and see if it helps...

Original comment by NameBran...@gmail.com on 21 Jan 2011 at 10:09

[GoogleCodeExporter]

Forgot to mention as soon as i turn on speakerphone and leave it on people can 
hear me again.

Original comment by NameBran...@gmail.com on 21 Jan 2011 at 10:10

[GoogleCodeExporter]

Maybe an option to dim the screen 100% and turn home buttons off when keep 
awake while in call is selected if the first option doesnt work.

Original comment by NameBran...@gmail.com on 21 Jan 2011 at 10:20

[GoogleCodeExporter]

here is a log if it will help.

Original comment by NameBran...@gmail.com on 21 Jan 2011 at 10:29

Attachments:

• Log.txt

[GoogleCodeExporter]

You are absolutely correct. If I turn the speakerphone on people can hear me 
again. However a minute later they can't and I have to turn speakerphone back 
off to get the outgoing sound working again. Even if I select "use routing api" 
and "use mode audio api", with speakerphone on, the other party can't hear me. 
I would have to toggle speakerphone on and off every minute to keep the sound 
going. It looks like "automatic speakerphone on" setting wouldn't fix the issue 
on my phone. 

The problem doesn't occur when I turn on "keep awake while on call". However 
the battery will probably die fast with this setting turned on, so I would 
consider it as a temporary fix only.  

I know, r3gis.3R., you will probably say this: "Keep awake while in call is a 
well well known work around used for devices such as HTC devices and Dell 
streak that have the PSP behavior.
This behavior is the following : when screen goes off, the wifi card comes in a 
state where data packets are not received as frequently as it should ..." 
But my screen doesn't go off when the bug occurs. I'm not using wifi only, it 
happens on 3G. Also how is it possible that other sip applications, like 
sipdroid for example, are not affected by so called psp or wifi bug? 

I understand you will activate the "Keep awake on call" by default for my 
device. I already sent you a log once before. Do you need another one? 
Let's hope android 2.3 will fix this issue if it's ever going to be released 
for my phone because I heard some rumors that it ain't gonna happen. 

Original comment by gmgem...@gmail.com on 22 Jan 2011 at 9:45

[GoogleCodeExporter]

Ok, so if it does occur even on 3g it's not PSP problem. This known bug only 
appear on wifi. So probably something else on Droid...

Original comment by r3gis...@gmail.com on 22 Jan 2011 at 11:03

• Changed title: Droid 2.2.1 support.
• Changed state: Accepted
• Added labels: Manufacturer-driver

[GoogleCodeExporter]

Quick additional question, on sipdroid the screen goes actually off on your 
device (I mean no black screen but really off)?

Cause on Sipdroid I'm wondering if the default behavior is not not keep the 
screen awake regardless the device. What I use to use proximity sensor to have 
screen going off is a private API and not sure that sipdroid devs has made the 
choice to use this private API.

Original comment by r3gis...@gmail.com on 22 Jan 2011 at 11:11

[GoogleCodeExporter]

In sipdroid the screen turns off and is being deactivated. In your app, with 
"keep awake while on call" setting on, the screen dims but it's still active. 
But when I turn off "keep awake while on call" the screen turns black and is 
being deactivated. 

Original comment by gmgem...@gmail.com on 23 Jan 2011 at 12:17

[GoogleCodeExporter]

I have been using csipsimple last few days a lot. Of course the "keep awake 
while on call" setting was on. It drained the battery fast and sometimes screen 
would activate functions while in call on accident (very annoying). I found a 
simple workaround for this issue. I turn off the screen after establishing a 
call by pressing the power button. The screen turns off and is inactive. I have 
to press the power button before I hang up or use the phone again. 

Original comment by gmgem...@gmail.com on 3 Feb 2011 at 5:20

[GoogleCodeExporter]

I did a commit today to try to add a cpu lock. I'm wondering if droid does not 
go in CPU sleep mode which could explain what you observe.

The build will be available tonight as revision 602.
I'll maybe force a build when I'll be back home to allow you to test before ;).

Original comment by r3gis...@gmail.com on 3 Feb 2011 at 5:31

[GoogleCodeExporter]

Can you supply a direct link to the version with the possible fix. Im. 
Confused. As to where to find it. Thanks

Original comment by NameBran...@gmail.com on 4 Feb 2011 at 8:19

[GoogleCodeExporter]

Of course : http://nightlies.csipsimple.com/trunk/

Let me know how it goes. I don't know if it will fix but for now I have no 
other idea. Just to be sure you have no "setCPU" app (to under clock/overclock 
the CPU) installed on the phone?

Original comment by r3gis...@gmail.com on 4 Feb 2011 at 8:40

[GoogleCodeExporter]

Yes. I do have SetCPU installed on the phone. Do I need to uninstall it for 
testing? Also I cannot find revision 602 for download in nightlies. 

Original comment by gmgem...@gmail.com on 4 Feb 2011 at 11:22

[GoogleCodeExporter]

@gmgem : My bad, it's revision 620 not 602. Sorry ;) 
http://nightlies.csipsimple.com/trunk/CSipSimple-r620-trunk.apk

As per setCPU have a look to issue 671. You should check that there is no 
profile in setCPU that reduce CPU speed when screen goes off :). Else obviously 
cpu speed will be reduced while csipsimple need it.

However as I said on issue 671 I'm interested with results of test with r620 
and cpuset activated with this profile to see whether my cpu lock introduced in 
r620 is useful when another app decide to reduce cpu speed. 

Original comment by r3gis...@gmail.com on 5 Feb 2011 at 9:11

[GoogleCodeExporter]

I have very good news for you. It appears, from initial testing, that revision 
620 fixes the problem. I've been on the call for couple hours yesterday without 
any issues. 

As far as SetCPU goes I've never used profiles in it. So I just created one for 
testing. My phone froze when I tried to use Csipsimple with the profile 
enabled. It looks like your cpu lock did not override SetCPU settings.

Also originally my SetCPU was set to "ondemand", min:250 and max:1000. 
Apparently such settings were affecting Csipsimple performance. I had to change 
settings to "performance" which basicly locked processor in 1000MHz. 

Original comment by gmgem...@gmail.com on 14 Feb 2011 at 2:28

[GoogleCodeExporter]

Ok, thanks a lot for testing.
So I should have a look to setCPU program and ask them if possible to acquire a 
CPU lock on their software.
I rename the issue to track SetCPU support with this issue.

Original comment by r3gis...@gmail.com on 14 Feb 2011 at 7:35

• Changed title: Workaround SetCPU

[GoogleCodeExporter]

Issue 1927 has been merged into this issue.

Original comment by r3gis...@gmail.com on 1 Sep 2012 at 2:13