#601 Workaround SetCPU

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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 : https://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).

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

This issue seems directly related to my issue https://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...

[Anonymous]

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

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

[Anonymous]

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

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.

[Anonymous]

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

here is a log if it will help.

[Anonymous]

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

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.

[Anonymous]

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

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...

Summary: Droid 2.2.1 support.
Labels: Manufacturer-driver
Status: Accepted

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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 [r602].
I'll maybe force a build when I'll be back home to allow you to test before ;).

[Anonymous]

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

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

[Anonymous]

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

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?

[Anonymous]

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

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

[Anonymous]

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

@gmgem : My bad, it's [r620] 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.

[Anonymous]

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

I have very good news for you. It appears, from initial testing, that [r620] 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.

[Anonymous]

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

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.

Summary: Workaround SetCPU

[Anonymous]

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

Issue 1927 has been merged into this issue.