No audio / Poor audio on Nexus One

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Make or receive a call
2. Observe no/poor audio from CSipSimple to other party
3. Observe audio from other party to CSipSimple is OK

What is the expected output? What do you see instead?
Good audio in both directions

What version of the product are you using? On what operating system?
0.00-12
Nexus One phone
Android 2.2

Please provide any additional information below.

I have yet to make a call with CSipSimple in which the other party does not 
complain of no audio or of very poor audio.

On the majority of calls there is no audio from CSipSimple to the other party.  
When there is audio, it is delayed, choppy, and low volume.

Calls using other Android SIP software (SIPdroid, SIPAgent/3cx) work fine.

Original issue reported on code.google.com by jropal...@gmail.com on 12 Jul 2010 at 2:14

[GoogleCodeExporter]

Really strange : I don't observe this behavior on my nexus one (2.2 too). 
Quality is really good in both ends.

Can you provide me the following information :
* What is your network transport ? wifi/3g/edge (good reception or not? - this 
can really impact the call quality - not the volume but delays and choppy).
* What is the type of phone used by the remote part?
* Have you tried to make a call just after a phone boot (when no other sip 
application has been started before). 
If you have other sip client or android media application that doesn't handle 
properly media resources, it's possible that they left audio layers in a bad 
state.
* Can you guess what codec is used for the communication (probably you can see 
it on the remote part if a sip phone is used - I didn't implemented it yet)?

Btw, call quality should be equivalent to SipAgent/3CX (which use exactly the 
same stack than us but didn't release their project as an open-source). And 
should be better than sipdroid since they use a java stack which is in theory 
slower.

Thanks for your report.
Any information you can provide are valuable to improve the soft .

Original comment by r3gis...@gmail.com on 12 Jul 2010 at 3:01

[GoogleCodeExporter]

Thank you for the quick response!

I am making calls through CallCentric - see www.callcentric.com.

My network here is WiFi.  I have very good signal - I am very close to the hub. 
 Uplink is more than fast enough to handle VoIP bandwidth, even with G711.

All my calls have been to other parties on the PSTN or GSM network.  I.e., 
CallCentric is relaying out to the PSTN for me.

I have tried calls after phone boot, yes.  CSipSimple starts automatically when 
the phone is booted.  I still get the complaints.  When I exit CSipSimple and 
then call with 3cx folk respond with "I can hear you perfectly now - that's 
much better".

I am guessing the codec would be G711.  But I have no way of knowing for sure.

What Audio Settings do you use on the N1?  I have:
    Echo Cancellation: YES
    Voice Audio Detection:  YES
    Auto Close Time: 1
    Media Quality: 4
    Clock Rate: 16kHz

I have played around with these but don't seem to be able to make any 
improvement.  Tell me your recommended settings for the N1 and I will try them.

Original comment by jropal...@gmail.com on 12 Jul 2010 at 3:20

[GoogleCodeExporter]

Further info... I just tried a call with these settings with good results:

Echo: NO
VAD: NO
Auto-Close: 1
Media Quality: 5
Clock: 16

Original comment by jropal...@gmail.com on 12 Jul 2010 at 3:26

[GoogleCodeExporter]

Many thanks for all theses precision.

I think that VAD is the key of the success in your case. I think that it acts 
like if your micro receive sound at a really low level I think.
I made a lot of experiments on that point, concluding that putting phone in 
"IN_CALL" put the micro in a state in which it give sound at a really low level.
On this base, I decided to not put the phone in the IN_CALL mode (unless 
android version is lower than 1.6 because it is the only way to make the output 
on the earpiece).

What I think is that on your phone, for an unknown reason, something put your 
media layer in this IN_CALL mode. I though that it was another program that put 
your phone in this state, but if you say me that directly after boot you get a 
bad sound quality, I conclude that the default on your phone is probably 
IN_CALL_MODE.

So, I think that what I should test is to force the mode on my app to something 
different from IN_CALL_MODE in order to make sure strength of the micro is good.

I'll keep you informed when I'll get something testable for you.
Thanks again for this report and your tests !

Original comment by r3gis...@gmail.com on 12 Jul 2010 at 3:41

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by r3gis...@gmail.com on 12 Jul 2010 at 3:58

[GoogleCodeExporter]

OK, I'll wait until I hear from you.

In the meantime, what file is the code that handles the Media Quality value?  
Since I just changed it - without knowing what I am doing - I figure I should 
read the code to find out what it does!!

As for what may be setting the media mode... I do have 3cx installed.  But 
CSipSimple is the one that starts when the phone is booted, or when the WiFi 
signal comes up after I've been out of range.  Of course, perhaps 3cx is also 
starting and then exiting again too - I am not sure if I can tell.  I do not 
show any other media apps running with the exception of the N1's Voice Search 
app.  (I am using ATK to see this.)  There are other apps running - EMail, 
Clock, News and Weather, Power Manager, Clock, etc, but none seem to me to be 
apps that use the media stuff.

Original comment by jropal...@gmail.com on 12 Jul 2010 at 4:03

[GoogleCodeExporter]

Hi,

Here is a alternate build.
http://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-01.
apk 

You have to uninstall any previously installed version of CSipSimple before 
installing this one.

There is two thing that you can test :
* You can test several audio mode when the communication is established :
To do so :
Go to the settings > Media > Scroll down to the last field and you can switch 
between each android audio mode. 
Let me know which is the best mode for the other party.

* I added a new option that allow to boost audio in both ends. VAD doesn't take 
this parameter into account. So, let VAD disabled if you use this parameter to 
boost your micro, else you'll get the choppy sound.

One last thing I changed related to wifi PSP mode allow you to force screen to 
not automatically turn off. See issue 71 for more details about this bug. I 
think that all recent nexus one and many HTC devices are affected by this 
issue, so you should *not* turn your screen off while in call else you'll get 
choppy sound.

Original comment by r3gis...@gmail.com on 17 Jul 2010 at 4:10

• Changed state: Started

[GoogleCodeExporter]

Sorry for the delay.

I am having a hard time testing this.  Once I turn Echo Cancellation and VAD 
off, all the other modes seem OK, with perhaps somewhat less clear INCOMING 
audio for the Invalid, Normal and Ringtone modes.  What exactly do you want me 
to test here... you've given me too many option combinations to know where to 
look for problems!  I'd like to give you a more precise answer.  I did see one 
alert pop-up box saying Audio Problem when using the default "No Change" mode, 
but was unable to repeat that, and the call audio was OK for other calls in 
that mode.

Am I supposed to be testing this with VAD on?  Please could you give me precise 
settings for each config option combination you want testing and I'll do them. 

A tangential comment... I have the app "Volume Locker" installed.  It resets 
the phone Ringer and Notification volumes should they be accidentally changed 
when the phone is in your pocket.  If you want to actually change these 
volumes, you change them, then press a confirm button on the screen - if that 
button is not pressed in a certain time (default 30 secs), Volume Locker resets 
the volume.  Now, CSipSimple and Volume Locker don't play well together.  
CSipSimple seems to set the In-Call volume, and if Volume Locker is enabled, 
Volume Locker resets the volume 30 seconds later.  Then CSipSimple changes it 
again and another 30-second cycle starts.  The two fight each other!  So I need 
to disable Volume Locker in order to use CSipSimple.  Any chance you can look 
at Volume Locker and see if it's possible to modify CSipSimple so that Volume 
Locker can stay on when using CSipSimple?

As for the screen-saver disabler, I am unable to get it to disable the screen 
(even turning off the new option).  My screen timeout is 1 minute, but the 
screen stays on, even when I do not touch the screen at all during that time.  
I know about the problems SIPdroid had with choppyness on the N1 when the 
screensaver timed out.  One thought... the N1 has a proximity sensor.  The GSM 
phone app uses that and turns off the screen when it's near your face and it 
does so without audio problems (of course, it uses GSM and not WiFi).  But 
perhaps explicitly turning off the screen might avoid the problems that happen 
when the screensaver timeout code turns it off?

I'll be away until Friday now, so can't test again until then.

Original comment by jropal...@gmail.com on 20 Jul 2010 at 10:46

[GoogleCodeExporter]

So first, you can try the latest build 0.00-12-06. 

I made things more stable with the audio. (Uninstall previously installed 
version before installing this one). 

Once installed, test with VAD and Echo cancellation disabled. 
If it still don't work at all, you can test disabling all codecs except 
PCMU/PCMA (if you are using a wifi connection it will be ok with bandwidth).

For the issue with Volume Locker, i'll try to see what is happening (but it is 
possible that last update solve the issue of looping between the two apps).
CSipSimple doesn't listen for volume changes to change it again. So in theory, 
if another app change the in call volume, CSipSimple will not change it again. 
Unless this is a feature from the android OS but if so, that should be managed 
by the Volume Locker application.

As for screen lock, proximity sensor support is planned. 
Besides, the last version fixes issues with screen lock. Now it will lock only 
in "dim" mode (low screen back light).
The issue with choppy sound happen each time screen is off (whether it is 
automatic or not). So my solution to this problem is "only with wifi sip calls 
lock screen in dim mode while in call" (and there is an option to disable for 
devices without this issue).
For now, this is done not only for wifi and doesn't take into account the 
proximity sensor. But will be done :)

Original comment by r3gis...@gmail.com on 25 Jul 2010 at 6:23

[GoogleCodeExporter]

Hi r3gis.3R, 

I'm the developer of Volume Locker, and just put out a release which allows for 
you to override the default settings of Volume Locker (so it doesn't set it 
off).  When you make your changes, you just need to fire off a broadcast intent 
which forewarns Volume Locker (or any other app using the open intent) to 
ignore the changes about to occur.  There are a few apps out there already 
using it (Locale has support, etc).  

If you want to implement it, here's a relevant project which calls the 
OpenIntent: 
http://code.google.com/p/locale-audio-update-notifier/source/browse/src/com/yuri
volkov/android/locale_audio_update_notifier/TheService.java

The actual OpenIntent page: http://www.openintents.org/en/node/380

Let me know if you need any other information or have questions.  

Thanks,
Jeremy

Original comment by jrluc...@gmail.com on 16 Aug 2010 at 4:56

[GoogleCodeExporter]

Fantastic !!!

I'll do the change right know (and maybe ask you if I have questions about what 
to send and when - but links sounds to answer everything). 

Many thanks !

Original comment by r3gis...@gmail.com on 16 Aug 2010 at 6:10

[GoogleCodeExporter]

Haha, not a problem.  I can attach the test code I used to validate that my app 
was working with it properly (it's very straight forward code).  Basically 
whenever the volume needs to change, you fire off a broadcast intent.  The 
other apps should know how to handle it within their own context (in my case I 
ignore the change in volume levels, etc).

If you open up that sample project I sent you, just search down to the line 
with the comment "And this is the reason of the plug-in existence:", and the 
lines below that are the relevant part.  

Feel free to let me know if you have any questions :D

Thanks,
Jeremy

Again

Original comment by jrluc...@gmail.com on 17 Aug 2010 at 1:26

[GoogleCodeExporter]

Revision 199 (http://code.google.com/p/csipsimple/source/detail?r=199) contains 
changes that does broadcasting before changing media volume.
Not tested with volume locker, but should be ok.

Just a question : openintent announce that it should be sent as a "Ordered 
broadcast" and as I can see in the locale plugin, it is sent as simple 
broadcast. Not really important since I don't take result into account. But 
should it be done?

Original comment by r3gis...@gmail.com on 17 Aug 2010 at 2:22

[GoogleCodeExporter]

Ideally it should be since an app can deny the volume change in theory.  In the 
case of that plugin, Locale has already changed the volume so it's just a 
post-volume change warning instead of a validation event.  

Volume Locker will never deny the volume change, since the user is given an 
option to accept it and holding the intent for up to 30 seconds is extreme.  
However, another app might.  

So, it's your call whether or not you want to use it in that manner (personally 
I'd just ignore it for now since you don't care about the result and there's no 
conflicts with anything at the moment).  ;)

Original comment by jrluc...@gmail.com on 17 Aug 2010 at 2:32

[GoogleCodeExporter]

Original comment by r3gis...@gmail.com on 3 Sep 2010 at 9:30

• Changed state: NextRelease