Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
[deleted comment]
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
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
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
This is now solved with latest release. Many thanks.
Original comment by kro...@gmail.com
on 24 Aug 2010 at 3:00
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
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
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
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
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
Still garbly version r618 on Nexus 2.2.2.
Original comment by kro...@gmail.com
on 14 Feb 2011 at 7:36
Original issue reported on code.google.com by
kro...@gmail.com
on 9 Aug 2010 at 11:03