Csip iLBC garbly, LinPhone iLBC ok.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Make phone call using iLBC codec.
2. Confirm iLBC using info.
3. Hear garbled sound.  Other end says sound ok, (not fantastic)

What is the expected output? What do you see instead?
Can make out what is said (just), but it's stuttery.

What version of the product are you using? On what operating system?
12-08 (although has existed since iLBC introduced) Nexus 2.2

Please provide any additional information below.
I've been hounding my provider over this thinking it was their end, as 
voicemail calls sound fine, but all outgoing calls stutter, garble bad.  But 
making the same calls using LinPhone (featureless android sip phone) sounded 
fine. 

Original issue reported on code.google.com by kro...@gmail.com on 9 Aug 2010 at 11:03

[GoogleCodeExporter]

Ok more information.  I have really tried to hammer out under what conditions 
iLBC works properly.  I have found by changing the media quality and clock 
rate, sometimes and only if I'm very lucky a call will sound ok.  Subsequent 
calls garble.

Sometimes quitting helps, but I haven't got a process that's guaranteed to work 
and I've been testing lots.  Suspect it's an initialisation issue, but app 
startup doesn't necessarily help.

Seems very random.

Original comment by kro...@gmail.com on 16 Aug 2010 at 7:59

[GoogleCodeExporter]

Thanks for the tests.

Can also be due to the fact when late at start time (due to an extra use of 
cpu) it goes worse and worse after. (It's probably more the case when it's an 
outgoing call since call user interface is created in the same time than media 
stream).

I've just build a new version with optimized build flags. My test show that 
using my htc magic for example gsm codec go from unusable to something near to 
be good. Not got at all for ilbc with my g2 but maybe could be good with nexus 
one (not tested since with high cpu and that support ilbc I have only my nexus 
one).

http://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-13.
apk

Let me know if things are better with this build.

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

• Changed state: Accepted

[GoogleCodeExporter]

No difference unfortunately.  BTW, the call doesn't get worse and worse.  It's 
bad from start to finish.  You can make out what is being said, but its all 
over the place, including the ringing sound.

Hope that helps.

Original comment by kro...@gmail.com on 16 Aug 2010 at 10:41

[GoogleCodeExporter]

Something that you can try... Just to test if it's due to a bad initialization 
of the audio layer is to try to enable bluetooth (even if you have no Bluetooth 
handset), then place a call and click on the bluetooth button. It will restart 
the audio stream (even if no BT device is associated). 
If it goes better then, it's probably due to a bad initialization (or init 
while cpu is overloaded).

Original comment by r3gis...@gmail.com on 16 Aug 2010 at 1:02

[GoogleCodeExporter]

And I forgot, try to disable echo cancellation and vad. Maybe it can help the 
cpu.

Original comment by r3gis...@gmail.com on 16 Aug 2010 at 1:04

[GoogleCodeExporter]

We are maybe not alone with this problem (pjsip+arm+ilbc)....
http://comments.gmane.org/gmane.comp.voip.pjsip/11623 
I've just tested with my archos 5IT <-> nexus one. And sound is clear during 3 
or 4 seconds and then becomes totally blocked and then again same thing cycling.
Maybe some changes in pjsip that break ilbc on low cpu devices.

Original comment by r3gis...@gmail.com on 16 Aug 2010 at 2:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I think that I got it :)
Just change the ilbc mode from 30 to 20 (absolutetly no idea of what does that 
mean...) But the result is that call quality between my nexus one and my archos 
5 it is really better now.

Let me know if it is better for you with 0.00-12-14 (another build available on 
the download section )

Original comment by r3gis...@gmail.com on 16 Aug 2010 at 3:36

[GoogleCodeExporter]

30 and 20 are ms for packet sizes.  30ms packet is more common among providers 
(mine doesn't support 20ms), and uses less bandwidth (due to fewer but larger 
packets - less headers).  I tested anyway, and strangely the quality is about 
the same.  

Before and now if GSM was in the list, the connection would skip over iLBC and 
go with GSM.  iLBC is only chosen if all other options are disabled, so I 
suspect I'm getting some kind of fallback connection.  Nonetheless, stick with 
30ms, it's smaller, more supported and probably sounds better.

Thanks for your effort so far.

Original comment by kro...@gmail.com on 16 Aug 2010 at 10:44

[GoogleCodeExporter]

Ok, what probably happen on your config is that as I set 20ms as the default 
now, ilbc is chosen only if there is no other solution and fallback to a 30ms 
as your sip provider doesn't allow it. So the result is effectively the same 
since you are still testing with 30ms instead of 20ms (that works really 
better).

There is probably a bug (/ incompatibility with buffer size) while using 30ms. 
I'll do more tests today and maybe ask support from pjsip guys.

Original comment by r3gis...@gmail.com on 17 Aug 2010 at 6:29

[GoogleCodeExporter]

This is now solved with latest release.  Many thanks.

Original comment by kro...@gmail.com on 24 Aug 2010 at 3:00

[GoogleCodeExporter]

Marked as fixed in 0.00-12-22

Thanks goes to Ben (: 
http://code.google.com/p/csipsimple/issues/detail?id=146#c24) ;)

Original comment by r3gis...@gmail.com on 24 Aug 2010 at 4:52

• Changed state: Fixed

[GoogleCodeExporter]

Actually with Dev 13-02 ILBC shound is horrible. I get speaker static and 
crackling sounds as if there is horrible interference within the phone. I am 
using a Telus HTC Hero with VillainRom 12 (android 2.1). When I switch to GSM 
the sound is ok. 

Original comment by dcitele...@gmail.com on 30 Sep 2010 at 4:46

[GoogleCodeExporter]

AFAIK, iLBC is disabled by default on HTC Hero. There is a good reason for that!
iLBC is not supported by "old" devices.
Let me explain :
iLBC opensource implementation (that we use), is a floating point 
implementation. As a consequence to have something efficient, the native 
library *must* be build with floating point instructions. It's impossible until 
armv7a (for example nexus one, galaxy s, etc). 
On HTC Hero (and all the old generation), there is no way to build in floating 
point. So application will keep transforming floating to non-floating datas 
which will overload cpu and make an horrible sound !

So, if iLBC is disabled by default on your phone... you should not use it ! 
Unless you have a big armv4 cpu (that's the reason why I didn't remove it from 
the armv4 build)... but usually it's not much more than 800mHz.

Original comment by r3gis...@gmail.com on 30 Sep 2010 at 5:16

[GoogleCodeExporter]

ok so retail version maybe should not even show the codec on devices where it 
is not supported.

Original comment by dcitele...@gmail.com on 3 Oct 2010 at 3:23

[GoogleCodeExporter]

Could work on armv5t cpus (on my comment #14 there is a mistake it's not armv4 
that I would say it's armv5). 
It will just be much more less performant.
By default it's disabled for non floating cpu and enable it for floating cpu. 
If somebody has a strong armv5 cpu... I must give hime a way to use iLBC ! 
Some armv5 goes up to 1.25gHz ! Not sure that in this case iLBC is really 
unusable !
In general mainstream users, will not go in those advanced settings. 
I think that if an advanced user goes in this settings and try to activate ... 
he will be disappointed first... then will search why it is so bad... and here 
... we could add something on the documentation.
But I don't want to put limits to users. 
My approach is :

Something automatically well configured for mainstream users
Easy ways to configure their sip account for mainstream users
Mainstream users want an easy setting interface

BUT : ways for power users to tweak the app if they have particular needs.

User friendly but leaving the user free :)

Last note, regarding this remark : for now, I've still to separate things in 
settings and add an "advanced setting section", since many things here should 
not be proposed to mainstream users.

Original comment by r3gis...@gmail.com on 3 Oct 2010 at 4:34

[GoogleCodeExporter]

Still garbly version r618 on Nexus 2.2.2.

Original comment by kro...@gmail.com on 14 Feb 2011 at 7:36