#86 No audio / Poor audio on Nexus One

[Anonymous]

Originally created by: jropal...@gmail.com
Originally owned by: r3gis...@gmail.com

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.

[Anonymous]

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

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 .

[Anonymous]

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

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.

[Anonymous]

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

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

[Anonymous]

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

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 !

Status: Accepted

[Anonymous]

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

(No comment was entered for this change.)

Owner: r3gis.3R

[Anonymous]

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

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.

[Anonymous]

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

Hi,

Here is a alternate build.
https://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.

Status: Started

[Anonymous]

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

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.

[Anonymous]

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

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 :)

[Anonymous]

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

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: https://code.google.com/p/locale-audio-update-notifier/source/browse/src/com/yurivolkov/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

[Anonymous]

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

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 !

[Anonymous]

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

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

[Anonymous]

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

[r199] ([r199]) 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?

[Anonymous]

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

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

[Anonymous]

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

(No comment was entered for this change.)

Status: NextRelease