RTP outgoing auto jittery / poor quality

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Make a call
2. Capture and examine RTP packets.
3.

What is the expected output? What do you see instead?

One RTP packet should contain 20ms of audio or so, at least this is what
asterisk does.

What version of the product are you using? On what operating system?

0.9 on Android 1.5

Please provide any additional information below.

The RTP payload is to be 1024 bytes in size, when asterisk sends 160 byte
payloads.

Original issue reported on code.google.com by scott.wi...@gmail.com on 29 Apr 2009 at 1:03

[GoogleCodeExporter]

Also noted in this doc from cisco that a RTP G.711 packet payload should be 160 
bytes
and 20ms. 

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094a
e2.shtml

Original comment by scott.wi...@gmail.com on 29 Apr 2009 at 1:35

[GoogleCodeExporter]

Most implementations will work just fine with multiples of 10ms (Asterisk 
included).

Are you saying the ptime in the SDP is set to 128ms?  That doesn't sound 
correct.

I suspect that this ticket would need a bit more information to be able to 
proceed. 
Simply having jittery audio doesn't imply (by any means) that an implementation 
is
doing the wrong thing.  It very well could be cellular network issues.

Original comment by NorthAnt...@gmail.com on 5 May 2009 at 9:59

[GoogleCodeExporter]

The packet sizes and ptime were observed by capturing RTP packets while a call 
was in
progress with an Asterisk server on a local network. Asterisk sent RTP packets 
with a
ptime of 20ms, sipdroid 0.9 sent packets with a ptime of 128ms.

The Sip/SDP invite message from sipdroid does not include a ptime attribute. I 
would
assume that the ptime for rtp is simply not set and defaults to 128ms.

This causes jitter/poor audio quality when used on the internet, or other 
larger,
delay prone networks.

This can be seen in the attached pcap file.

Original comment by scott.wi...@gmail.com on 8 May 2009 at 1:55

Attachments:

• 1024k_rtp.pcap

[GoogleCodeExporter]

I think i got the same kind of problem. Got a poor sound quality too from the 
SIP
account of my ISP.

i'm using Wifi (as using SIP on 3G or Edge is forbidden on SFR), and streaming 
audio
don't cause some jitter.

note that i don't have that problem using X-lite or ekiga on this account with 
wifi.

i'm using sipdroid 0.9.5

Original comment by lenas...@gmail.com on 31 May 2009 at 1:27

[GoogleCodeExporter]

Issue 69 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 10 Jul 2009 at 4:23

[GoogleCodeExporter]

I have the same problem, when I try to call on a dahdi channel passing from my
asterisk, I can hear well, but on the other side the call is not intelligible. 
It
seems that packets containing voice arrives too late so the result is choppy 
voice.
I'm using sipdroid 0.9.10 on HTC magic connected throught wifi

Original comment by f.crisci...@gmail.com on 12 Jul 2009 at 7:44

[GoogleCodeExporter]

Has anyone managed to create a workaround for this on the code side?
(even just to point out how to fix it)
I have tried to force sipdroid with ptime 20ms and other attributes I saw with 
Wireshark on X-Lite such as
a=fmtp:101 0-15
a=rtpmap:107 BV32/16000
a=rtpmap:101 telephone-event/8000
a=sendrecv

This didn't seem to resolve the poor outgoing audio

Original comment by arnonse...@gmail.com on 12 Jul 2009 at 7:29

[GoogleCodeExporter]

I have the same problem (poor outgoing sound quality) but on pbxes test call 
(*43) sound is good

Original comment by ernest.z...@gmail.com on 18 Jul 2009 at 3:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I also tried to copy/paste sip config from pbxes but the result is the same, 
voice
incoming to sipdroid is very good, on the other hand voice outgoing from 
sipdroid is
choppy.

Original comment by f.crisci...@gmail.com on 28 Jul 2009 at 5:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Issue 110 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 8 Aug 2009 at 8:56

[GoogleCodeExporter]

My problem (poor outgoing sound quality) gone away  after changing my ROM to 
CyanogenMod v4.0.1 from ADP 1.5 Google

Original comment by ernest.z...@gmail.com on 20 Aug 2009 at 12:41

[GoogleCodeExporter]

Sipdroid now sends 160 byte payloads.

Original comment by pmerl...@googlemail.com on 3 Sep 2009 at 8:24

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for the fix!  Outgoing audio has been perfect over WiFi since 1.0.5.

Original comment by anders...@gmail.com on 3 Sep 2009 at 8:27

[GoogleCodeExporter]

I spoke too soon, outgoing audio is cutting out again with 1.0.6 and 1.0.7.  I
suppose it could just be a fluke.  If I get a chance I'll try going back to 
1.0.5 to
see if it still works.

Original comment by anders...@gmail.com on 4 Sep 2009 at 2:23

[GoogleCodeExporter]

Tried 1.07 and problem persists. Please re-open this issue. 

Original comment by neil.ohe...@gmail.com on 4 Sep 2009 at 8:43

[GoogleCodeExporter]

Issue 69 has been left open for jitter problems with Asterisk. This issue dealt 
with 
the frame size and because it was changed this issue was closed.

Original comment by pmerl...@googlemail.com on 4 Sep 2009 at 12:56

[GoogleCodeExporter]

I don't think the issue is just with Asterisk.  I'm using Gizmo5 via pbxes.org 
and
choppy outgoing audio returned for me with 1.0.6 and 1.0.7.

Original comment by anders...@gmail.com on 4 Sep 2009 at 8:05

[GoogleCodeExporter]

I'm having the same issue with 1.0.7, using a VoIP service provided by my ISP.
Outgoing audio is choppy, incoming seems to be fine. Other (softphone) SIP 
clients
are OK.

Happy to do a little diagnosis if it'll help, just let me know what you need.

Original comment by jeremymeep@gmail.com on 9 Sep 2009 at 3:22

[GoogleCodeExporter]

Tried 1.0.7, 1.0.8 and 1.1.1 to make calls from emulator to x-lite, linphone and
ekiga using Asterisk. 

My tests show that the emulator side hears good quality audio, but the 
softphone side
hears jitters and choppy audio, while softphone to softphone calls shows good 
quality
on both sides. Of course, emulator to emulator shows choppy audio for both ends.

@ernest.zielinski: changing your ROM fixed the quality? does this mean that 
choppy
audio is caused by poor Android emulator/device performance? 

Because my tests confirms all softphone calls to have good quality on PBXes, 
Gizmo
and Asterisk, and choppy outgoing audio persists on Sipdroid regardless of what
server is used.

I doubt this is an audio codec problem, but I'm not sure...

So is this network, performance or codec problem? Any thoughts?

Original comment by Silversp...@gmail.com on 1 Oct 2009 at 9:28

[GoogleCodeExporter]

Same issue here with 1.1.3 on Android 1.6, drc83. Been using Ekiga and other 
hard
phones with Asterisk without any problems for quiet some time. G1 and Sipdroid 
are
connected via local WiFi. Very little latency, or anything network wise that 
could
cause problems. Couple installs of Ekiga use the same WiFi. Seems pretty 
specific to
Sipdroid. However I am running Asterisk 1.2.35, and > 1.4 has a new jitter 
buffer.
Though not sure that should be required to overcome some issue on the other 
end. If
it would help at all with this problem.

Sound quality to me is great on the G1 via Sipdroid, quality on the other end,
transmitting from the G1 is very choppy and jittery, just as others reported.

Original comment by wmlthoms...@gmail.com on 16 Oct 2009 at 9:45

[GoogleCodeExporter]

After testing pc-based softphones to sipdroid on emulator some more, like what 
I did
in comment 26, the results are, by far, consistent, that outgoing audio is 
jittery.
In contrast, softphones like x-lite, linphone and ekiga, when used to call each 
other
using asterisk, shows good quality, I guess it implies that network capacity and
asterisk management of audio is not the problem.

Three suspects left, emulator/device performance, emulator unoptimized use of pc
bandwidth, and unoptimized audio encoding.  

The emulator is launched using "emulator -avd <avd_name> -netspeed full" for 
full
usage of the pc's bandwidth.

A audio loopback mechanism is then created in RtpStreamSender.java (by 
initializing a
new audiotrack object, apart from the one created in RtpStreamReceiver, and 
calling
track.write() to output the sound to the speaker), a test was conducted using
sipdroid on an emulator to call x-lite in a different pc using asterisk.

First, the lin (short array) from record.read() was fed to the G711.encode() to
produce buffer (byte array) which was again fed to G711.decode() to produce lin2
(short array) that was fed to track.write(). This test was effective in 
producing an
echo output of your own voice with 1 sec delay from the time the words are 
spoken.
This test shows poor audio quality and lots of jitters after the first three 
seconds
of call, similar to my test shown in Comment 26.

The second test is a slight variation of the former one, however, instead of 
going
through G711 encoding and decoding, the extracted lin from record.read() is fed
straight to track.write(). This test shows exactly the same results as the 
previous
test. I guess this implies that encoding and decoding doesn't diminish the 
quality,
thus is not the problem.

The only suspect left is performance.

I made a rush audio recording application and tried to record my own voice to 
compare
the quality from loopback versus that of recorder playback. This test shows 
that the
voice quality from these two methods are almost the same. The same is true in 
using
the default android sound recorder. This implies that the problem is not 
processing
performance, but the android OS's way of extracting audio stream from the mic.

I don't know if the same is true for G1 and other HTC devices, but in the case 
of the
emulator, the audio quality extracted from the MediaRecorder object is simply 
not of
pleasing quality, now I suspect to be the cause poor audio quality heard on 
other sip
clients.

I hope these helps, please do pause other test results as well so we can
prove/disprove this hypothesis...

Original comment by Silversp...@gmail.com on 22 Oct 2009 at 3:28

[GoogleCodeExporter]

Audio stream from x-lite to Sipdroid via Asterisk is clear, only the stream from
Sipdroid to x-lite is not, this suggests that the Asterisk's jitter buffer
implementation is enough to deal with network-related packet delays..

After performing audio loopbacks, we have discovered that audio-in streams 
extracted
using the AudioRecord API is already jittery. Likewise, after testing a rough 
voice
recorder application using AudioRecord API, results show that either the API is
causing the jitter problem or the Android Emulator itself.

After reading some online feedbacks on audio-in quality of G1 phones using GSM 
calls,
it suggests that the API isn't the problem, unless the Android GSM calls is 
using a
different audio-in API. 

To finally conclude this, I've recently tested Sipdroid 1.2.2 on Samsung 
Behold, and
audio quality is almost perfect. Which therefore shows that Android Emulator 
really
has audio-in quality problems, must be the virtual drivers not being optimally
functional.

Original comment by Silversp...@gmail.com on 22 Dec 2009 at 6:05

[GoogleCodeExporter]

I have submitted a patch in the notes in issue 69 that may be relevant to this 
issue,
too.

Original comment by jropal...@gmail.com on 19 Jan 2010 at 3:58

[GoogleCodeExporter]

Still experiencing this with 1.3.3 beta which I assume uses above mentioned 
patch.
Also I have upgraded to Asterisk 1.6 and enabled the SIP jitter buffer. Still 
playing
with that, but no difference. Also tried both UDP and TCP. Nothing seems to 
make any
difference. However a few versions prior to the last ones. The jitter was 
present on
audio both receiving and sending. Now it's back to just sending. Also I can 
hear the
jitter as an echo while I am talking. So I can tell it's happening just as the 
other
end can. Seems to be core to the API or hardware, not sipdroid specific per se. 
Just
shows up here, because it will be a popular app once this issue is resolved. I 
will
be using it daily and likely more than any other app on my phone.

Thanks for everyone's continued effort on this. I am happy to do my part, but 
have
yet to really roll up my sleeves. Sorry about that, if I can help in any way, 
let me
know.

Original comment by wmlthoms...@gmail.com on 20 Jan 2010 at 2:42

[GoogleCodeExporter]

No, the patch has not been accepted into the main code yet.  You are running 
code
which does not contain this patch.  To try the patch at the moment, you will 
either
need to build your own .apk from code that you apply the patch to or wait until 
one
of the project's developers reviews the patch and includes it.

To expedite that, you might want to email the developers and request that they 
look
at this again as there doesn't appear to be much attention to issue 69 at the 
moment.

I have had confirmation by email from someone else that the patch does work.

Original comment by jropal...@gmail.com on 20 Jan 2010 at 4:17

[GoogleCodeExporter]

Upon capturing packet data, i've noticed that the emulator has sent MORE rtp 
packets 
compared to the amount the phone sent. This makes me want to believe that there 
are 
still issues on the emulator itself. May i hear some opinions on this matter?

Original comment by jac...@gmail.com on 13 Mar 2010 at 8:41

[GoogleCodeExporter]

I added ptime attribute in addMediaDescriptor() method but still sipdroid not 
send
this attribute.

afvec.add(new AttributeField("ptime", String.format("%d", 50)));

Please help me where I have to add code to send ptime attribute

Original comment by patel.ro...@gmail.com on 19 May 2010 at 1:11