#352 High latency during a call using Galaxy S i9000

[Anonymous]

Originally created by: m.peccia...@gmail.com

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.

[Anonymous]

Originally posted by: m.peccia...@gmail.com

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

[Anonymous]

Originally posted by: m.peccia...@gmail.com

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

[Anonymous]

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

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

[Anonymous]

Originally posted by: m.peccia...@gmail.com

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    

[Anonymous]

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

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?

[Anonymous]

Originally posted by: m.peccia...@gmail.com

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

[Anonymous]

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

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.

[Anonymous]

Originally posted by: m.peccia...@gmail.com

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

trycage

[Anonymous]

Originally posted by: m.peccia...@gmail.com

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

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

Originally posted by: m.peccia...@gmail.com

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

[Anonymous]

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

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.

[Anonymous]

Originally posted by: m.peccia...@gmail.com

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

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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.

[Anonymous]

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

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

[Anonymous]

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

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.

[Anonymous]

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

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

[Anonymous]

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

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??

 

[Anonymous]

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

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.