High latency during a call using Galaxy S i9000

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Whatever codec I use during a call toward a land-line phone I  experience a 
delay in the transmission exceeding 2 seconds
2. I'm using the WiFi connection
3.
What is the expected output? Delays below 500mS during a conversation

What do you see instead? Delays exceeding 2S

What version of the product are you using? On what operating system?
Galaxy S i9000 <rooted>
Stock Android Eclair 2.1

Please provide any additional information below.
I disable the echo cancellation
and reduced the Frame ptime to 40 (for some reasons 
values below reduces significantly the quality of the call)

I'm using the VOIP provider messagenet   <sip.messagenet.it>
I do not experience the same problem using PC SIP software client.
I can ping my sip gateway with response time below 40mS from the mobile phone.

Original issue reported on code.google.com by m.peccia...@gmail.com on 7 Nov 2010 at 8:29

[GoogleCodeExporter]

Hi again, the effect is reproducible with the version 0.00-15-10. Indeed it 
seems to affect specifically the Galaxy S (something related the audio 
architecture or to the network buffering). The effect does not seems to affect 
other devices I tested.
I notice long delay also with other VOIP software, hence it may be a common 
architecture problem. Could someone with the I9000 give a feedback about this?

Thanks

Marco

Original comment by m.peccia...@gmail.com on 10 Nov 2010 at 9:44

[GoogleCodeExporter]

Dear All

an update,  I installed a SSH server in the galaxy S and logging inside using 
an SSH client I notice the same latency in the echo of the characters I digit.
(I receive the echo after 1-2 second). (If I time using a local terminal there 
is not such delay). It could be definitely something in the network.

I look forward for your feedback

Trycage

Original comment by m.peccia...@gmail.com on 10 Nov 2010 at 2:26

[GoogleCodeExporter]

Yes indeed sounds to be linked to the network or to the way android manage the 
network.
There is a well known bug on HTC device that enter in what they call "PSP mode" 
when screen goes off. In this case data packets are dropped or received with a 
high delay.
It's due to the fact the wifi card goes in a special mode (that is not sleep 
mode) which save battery but impact applications that try to get live packets 
from the network.

It could  be the same kind of problem on this device. What you could test to 
ensure it's not the case is to keep the screen on and try the same test with 
SSH (or with the app).
If it helps there is a settings that activate a workaround in csipsimple in 
settings > Userinterface > keep awake while in call (you've to switch to expert 
settings mode before : in Settings > press menu and choose "expert mode")

Original comment by r3gis...@gmail.com on 11 Nov 2010 at 9:43

[GoogleCodeExporter]

Thanks for you answer

The settings "Keep awake while on call"
and          "Use partial was lock"
seems to have no effect on the delay

I measured the delay using a loop-back service of my SIP provider (i.e. the 
loop-back is inside my SIP sub-net hence I can hear my echo in the fastest way 
possible). The total delay of a round trip is around 1-1.1sec using ILBC and in 
PCMU.
(it is interesting that the delay seems to not change with the streaming 
bandwidth)

There is no appreciable difference with the screen on or off (I also checked 
the effect of the lock of the screen due to the proximity sensor and it is none)

I also notice something interesting by testing with SSH. The echo of the first 
character I digit is always the longest, than if I quickly repeatedly digit the 
echo seems almost instantaneous. If I stop and start to digit again the echo if 
slow again. If seems somekind of sleep mode (however the VOIP packet streaming 
should be dense enough to avoid this ).

However still looking for the light. Can someone with a Galaxy S i9000 report 
his experience about this?

Trycage     

Original comment by m.peccia...@gmail.com on 11 Nov 2010 at 10:11

[GoogleCodeExporter]

Ok
Just FYI, I've tested on the galaxy S (i9000) of a colleague and didn't observe 
a high latency. 
Maybe the problem with SSH is another thing (maybe the implementation of the 
server you installed do things to save battery).

Did you try with another sip application on android with the same configuration 
(same SIP provider, same remote party and same bandwidth) (for example with 
linphone, or sipdroid?). Are the results better with one of these other android 
SIP app?

Original comment by r3gis...@gmail.com on 11 Nov 2010 at 10:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi,  It seems that the loop-back latency with SIPDROID (it is the only one, 
NIMBUZZ experience high latency too) is much lower about 300mS-600mS (It 
changes significantly from call to call), which is not perfect but good. 
However, SIP DROID indicates that it measure a latency between 80mS and 140mS 
(I'm not sure what this number refer to). What I did it simply to measure the 
delay between the echo in a loop-back call.

Shortly I experience a lower latency with SIPDROID

Trycage

Original comment by m.peccia...@gmail.com on 13 Nov 2010 at 2:06

[GoogleCodeExporter]

I have a Galaxy S (International) and never had this high latency.  Using 
Latest Froyo rooted custom firmwares (Doc's Roms).  I am willing to test if I 
can help.

Original comment by JRam...@gmail.com on 25 Nov 2010 at 10:14

[GoogleCodeExporter]

This would be great,
do you have the possibility to test the latency using an echo test with your 
sip provider?

trycage

Original comment by m.peccia...@gmail.com on 25 Nov 2010 at 10:21

[GoogleCodeExporter]

Ok I installed Froyo and things seems better.
(I also upgraded csipsimple to the latest version)
however my PC client stil largely outperform the galaxy S in terms of latency

It is quite strange however that csipsimple report a round trip RTT between 
40-50mS, but the real round trip is areond 400-500mS (measured using the audio 
echo)

trycage

Original comment by m.peccia...@gmail.com on 25 Nov 2010 at 11:05

[GoogleCodeExporter]

I am experiencing the same symptoms on my Nexus One.  Testing on a local 
Asterisk server I find CSipSimple to have ~1sec round trip delay on the echo 
test.  3CXPhone seems to be the same and SipDroid seems to be a bit better.  A 
hardphone (Siemens Gigaset) is near instant, so it's not the server.  Aside 
from the hardware involved the only other difference would be the wireless 
(DECT 1.9Ghz vs 802.11g 2.4Ghz).

I do notice that pinging my server from my phone seems to vary between 2ms-20ms 
while my laptop over the same wireless connection is consistently ~1ms.  So 
there does seem to be some quirkiness in the network stack on my N1.  However 
even with that 20ms*2 == 40 < 1000ms.

I'll wait for Gingerbread to drop and test with the built-in SIP stack.  If 
that fails I'll try rooting my phone to upgrade the radio's firmware and let 
you know of any changes.

Original comment by mactalla...@gmail.com on 25 Dec 2010 at 6:01

[GoogleCodeExporter]

For N1 & Galaxy S I've the two phones and I do not observer such a latency.
So should not be the phone nor the application. I guess that's something else. 
(Configuration? / Codec use?).

On N1 make sure that the screen doesn't turn off else you'll enter the PSP mode 
and packets will not be received as quickly as it should - search over this 
issue list PSP mode (on closed issue), you'll find a detailed explaination 
about what it is exactly.

However, after saying all of that I can announce that when I'll be able to have 
a 2.3 on my hand, I'll implement the audio stack using the new API introduced 
in 2.3 for sound (previously it was necessary to use java stack to be fully 
compatible with all devices - I had a driver that used private API but was not 
compatible with all devices). In 2.3 google has added OpenSL support so I'll 
add it to CSipSimple which may improve perfs.

Original comment by r3gis...@gmail.com on 25 Dec 2010 at 8:14

[GoogleCodeExporter]

Hi All

As I said, with Froyo  things improved and I can talk. I guess that there could 
be a dependence on the actual ROM installed. In any case there is a large 
difference between the reported latency (like 40-70mS) and the real one. I 
checked with sipdroid (which actually shows a lower real latency) but still the 
reported latency is smaller than the real one. (Even if I compared with half of 
a round trip)

I removed the echo suppression but nothing really changed. Is it possible to 
modify
the ptime value to reduce the delay (maybe?)?

Thanks

Trycage

Original comment by m.peccia...@gmail.com on 25 Dec 2010 at 8:41

[GoogleCodeExporter]

More testing and experimenting.  I have now upgraded my radio firmware (now on 
5.08.00.04) and also tried installing Cyanogenmod 6.1.

An attempt at better quantifying the latency puts it at ~400ms.  I don't know 
if this is an improvement over the past before factory reset et al, or whether 
I was overestimating the 1sec.  Something that I do notice is that pinging my 
phone over wifi cycles from about 25ms to 250ms.  This type of ping latency 
would 100% explain the audio delay.  When pinging FROM my phone I get 5-15ms.

@m.peccianti Do you experience similar high latency when pining your phone?
@r3gis.3R Do you have consistently *better* latency when pining your phones?

If this is indeed the case, this then bug is out of CSipSimple's scope and 
hopefully Google fixes it in Gingerbread.

Original comment by mactalla...@gmail.com on 27 Dec 2010 at 4:07

[GoogleCodeExporter]

Hi mactalla,

I think you got something else. actually When I ping my SGS I get something 
around 150-250mS. However if you go in call with CSIPSIMPLE (also with 
SIPDROID) the ping fall down to 2-3mS. In my opinion that is something related 
to the power management (when your mobile does nothing) 

trycage

Original comment by m.peccia...@gmail.com on 27 Dec 2010 at 9:43

[GoogleCodeExporter]

I confirm, exactly same results than trycage.

While in call sip applications take a "lock" on wifi which should change sleep 
policy of the wifi card (actually not on all device cause some need the screen 
to be on to be in this mode -PSP issue- but problem is not present on the 
galaxy S).

In this mode packets are received with the lower latency possible.

Another thing to check on your phone is if there is not another app that claims 
to save your battery and just prevent over apps from going in this mode.

Original comment by r3gis...@gmail.com on 27 Dec 2010 at 10:27

[GoogleCodeExporter]

You both are correct of course.  I hadn't been testing within a call.  Pings to 
my phone drop to 1-2ms with spikes to 35ms while a SIP call is active.  That 
lines up much better with the info CSipSimple is reporting in-call: RTT msec 
2-13ms, RX jitter: 0-18ms and TX jitter 33-53ms.

I'm surprised tx jitter is so high, but I don't think that's high enough to be 
the culprit.  My understanding was that jitter is out-of-order packets.  But 
how does that happen for TX?  Shouldn't the phone be transmitting everything in 
order?  I'm probably misunderstanding a part and it's probably inconsequential 
to the symptoms I'm experiencing.

I'll continue investigating.

Original comment by mactalla...@gmail.com on 27 Dec 2010 at 6:39

[GoogleCodeExporter]

Oh, something I'm just thinking about. Are you using the market version?

Cause if so, maybe worth to either 
* Try a dev version
* Increase thread count in settings
Cause in market version by default thread count is only 1 which is really bad 
(specially for echo tests) and have been changed in trunk for future releases.

Original comment by r3gis...@gmail.com on 27 Dec 2010 at 7:00

[GoogleCodeExporter]

Good point.  I had originally been using r502 but with all my system resets I 
went with the market version for ease of installation (maybe I should've used a 
bookmark..)

Now running r522 and the pings while in-call are improved (1-2ms with spikes 
only to 7ms).  Unfortunately there did not seem to be any improvement in audio 
latency.  I tried poking around in the advanced settings to no avail.  Thanks 
for the reset to defaults button!

MORE INFO:
I don't know why I didn't test this before.  An echo test doesn't tell us 
whether the delay is evenly distributed between encoding/sending or 
receiving/decoding.  I just tested with a phone instead of the echo server.... 
and sending is working perfect (near-instant).  Receiving, however, is 
responsible for all of the delay.

Does the underlying library provide any reports on the timings of data from 
when it's received to when it's sent to the speaker?  This would permit us to 
see if the delay is within the SIP stack or not.

Original comment by mactalla...@gmail.com on 27 Dec 2010 at 7:54

[GoogleCodeExporter]

Not AFAI, unfortunately (but would be tricky to do cause the stack does not 
really handle how the audio driver push buffers on the hardware).

However something that is known is that there is some progress possible on the 
step stack => hardware speaker. For now as android doesn't provide sufficient 
native binding to the audio layer it was required to pass buffer to java layer 
(actually the shortest path is to path directly to JNI layer).
This introduce a little latency and may be improved in the future cause from 
android 2.3, we will have access to OpenSL which will allow applications to 
talk directly to hardware without bothering with java. So it may improve things 
on some device (there is also a new private API for acquiring a lock on "high 
perfs wifi").

For the pure driver latency I estimate that using native instead of java will 
benefit about 20ms of improvement for in and out.

There is some tests tools however in pjsip (see 
http://trac.pjsip.org/repos/wiki/audio-check-sound-device-jitter)
I have a way to activate this test utility (I played long time ago with that ;) 
). If you are interested I can include that in next build but will require you 
to have the android sdk installed to see logcat.

Original comment by r3gis...@gmail.com on 27 Dec 2010 at 8:15

[GoogleCodeExporter]

I'm happy to install/test anything that might help us figure this out!
I'll go install the SDK in anticipation of the next build.

Original comment by mactalla...@gmail.com on 27 Dec 2010 at 8:21

[GoogleCodeExporter]

Have you included the test tools in the new build?  I have the SDK installed 
and am ready to perform whatever tests would help.

Original comment by mactalla...@gmail.com on 31 Dec 2010 at 1:38

[GoogleCodeExporter]

Yes, there is an option in Settings (if you are in expert setting mode) :
You press menu button in settings and there is an "Audio test" option. 
It will output some infos about the current audio driver in the logcat tool.
 * Activated debug mode on your phone (it's in android settings in application in development)
 * plug phone to your pc in usb
 * launch ddms on the PC 
 * In csipsimple turn on logging (in settings > user interface > log level -> 4)

And finally launch the "Audio test" option. Nothing will appear on the android 
phone screen but on ddms/logcat you'll have rapport of the pjsip stack about 
the audio driver. I'll try to add another basic test of local echoing so that 
we can actually test the latency just introduced by the audio driver. It will 
be probably also very interesting.

Original comment by r3gis...@gmail.com on 7 Jan 2011 at 11:33

[GoogleCodeExporter]

Attached is the libpjsip output.  I hope it's helpful.

Original comment by mactalla...@gmail.com on 9 Jan 2011 at 12:08

Attachments:

• csipsimple.pjsip.audiotest.txt

[GoogleCodeExporter]

First of all, thank r3gis.3R for the great app. I have an SGS I9000 purchased 
in India, and was unable to use any sip/voip application for a long time. There 
was too much lag even after upgrade to DDJP6 (Froyo - 2.2 verison for India). 
Last week i flashed my SGS with the XXJPY firmware and tried using sipdroid. It 
was better that before but still very jittery. I tried Csipsimple and 
everything worked fine if I used a lower quality coded (GSM, still bit laggy 
with PCMA/PCMU). I use Terrasip.net and I have to connect using a VPN as VOIP 
is blocked in UAE. After the upgrade to XXJPY the call quality is same as what 
i had earlier with my N900 & Nokia 5800. 

Maybe the upgrade to JPY solved the problem or simply reflashing the device did 
it?? 

Original comment by reddy...@gmail.com on 26 Jan 2011 at 8:55

[GoogleCodeExporter]

Indeed, Samsung tried to fix their driver. There is really well known problems 
on their side regarding their audio drivers with all their devices. I heard 
that they started to fix things.
I also use a JPY based ROM. So they surely fixed things... but there is still 
some problems with their drivers (specially regarding routing, I've still to 
apply a odd workaround). Hope that Samsung will improve their driver and that 
the experience they acquire with nexus S working with google will be backported 
to all their other devices.

Original comment by r3gis...@gmail.com on 26 Jan 2011 at 11:01

[GoogleCodeExporter]

Here is a tutorial on How to update Your SGS to I9000XFJS2 how to unlock it and 
how to root it http://www.sh-phones.com/?p=133

Original comment by balar...@gmail.com on 9 Feb 2011 at 4:46

[GoogleCodeExporter]

Marked as obsolete. In fact this problem is more relevant from something on 
samsung roms driver than something in the app.
Android has no real low latency devices for now. With upcoming stock SIP app, 
manufacturers are mare aware about the fact their audio driver should also be 
good when used from an application and not only from the phone GSM chipset.

Original comment by r3gis...@gmail.com on 7 May 2011 at 12:24

• Changed state: Obsolete

[GoogleCodeExporter]

I have exactly this issue with CSipSimple market version (1.02.03 r2457) on an 
HTC Desire 510. In particular, even though I'm using the Mode API and 
IN_COMMUNICATION mode, when I talk back and forth to myself on a second phone, 
anything I say to CSipSimple shows up on the other phone "immediately" but if I 
talk into the other phone, I hear it in CSipSimple around 1-2 seconds later. 

Also, the audio test mode, I count down ten to zero, and when I say zero, I 
then typically hear "one...zero" after I'm done, again indicating 1-2 second 
delays in the audio system.

Original comment by dlake...@gmail.com on 7 Mar 2015 at 4:19