hudamalmsteen / sipdroid

Automatically exported from code.google.com/p/sipdroid
0 stars 0 forks source link

Sound from android mic stutter on asterisk. The other end sounds clear #69

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Register to Asterisk server with Sipdroid
2. Place a call

What is the expected output? What do you see instead?
Expected: Both sides hear voice fluently
Actual: Only I hear the other party ok. They hear me stuttering

What version of the product are you using? On what operating system?
Sipdroid 0.9.11 . My phone OS is ADP1 Cupcake (official)

Please provide any additional information below.
This was tested with
1. Sipdroid to X-Lite softphone
2. X-Lite to sipdroid
3. Sipdroid to trunk (external line)

With X-Lite to trunk (no sipdroid) everything works fine

Original issue reported on code.google.com by arnonse...@gmail.com on 10 Jul 2009 at 4:19

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago
Hey I just had a similar problem.  I had two eth connections, eth0, and eth1, 
eth0
had no connection, I disabled eth0 and vooila! no more stutter

Original comment by nate.bar...@gmail.com on 20 Jul 2009 at 5:23

GoogleCodeExporter commented 9 years ago
I previously posted this comment to issue 10 because I thought issue 69 is just 
a
duplicate of 10, however issue 10 is only about the payload size and was thus 
closed,
so I reposted this here since its more appropriate:

I 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 from issue 10 says, by changing his ROM, the quality is fixed? 
Does
this mean that choppy audio is simply 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 the jittering problem a network, performance or codec problem? Any 
thoughts?

Original comment by Silversp...@gmail.com on 12 Oct 2009 at 5:28

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Since this is labled "Duplicate", does the author even look at this?

Original comment by arnonse...@gmail.com on 12 Oct 2009 at 12:47

GoogleCodeExporter commented 9 years ago

Original comment by pmerl...@googlemail.com on 12 Oct 2009 at 6:58

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
After testing pc-based softphones to sipdroid on emulator some more, like what 
I did
in comment 3, 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 3.

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:44

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I have exactly the same issue: outgoing audio from sipdroid is choppy when 
connected
to asterisk.

After a series of tests I realize the problem only appears when I change 
channels
(sip/isdn) on my path. Here is what I did:

szenario: sipdroid connected to asterisk connected to isdn (and other sip 
providers)

sipdroid calls echo test at asterisk: no problem
sipdroid calls out to external number: choppy sound from sipdroid, incoming ok
sipdroid calls out to external number via another sip-provider: no problem

incoming call via isdn no assigned to sipdroid: choppy sound from sipdroid only
incoming call via sip-provider-number: no problem 

I therefore figure that the problem must be at the asterisk converting channels 
from
sip to BRI and only in this direction. BTW I am running
Asterisk-1.2.13-BRIstuffed-0.3.0-PRE-1v

I have lots of other SIP extensions that work fine calling out on ISDN, only 
sipdroid
is causing this problem. So maybe its a frame-thing? 

Original comment by oakcam...@googlemail.com on 18 Nov 2009 at 10:49

GoogleCodeExporter commented 9 years ago
one more test is causing me a headache:

I reconfigured my asterisk to use allways outgoing sip provider for sipdroid.
when calling external number of another sip provider I run into the same old 
problem:
audio from sipdroid is stuttering.

Original comment by oakcam...@googlemail.com on 18 Nov 2009 at 10:52

GoogleCodeExporter commented 9 years ago
Hi,
I want to precise that I do not want to advertise another program, but I tried 
F****
on my magic, with the same configuration that I use with sipdroid and there is 
not a
problem on outgoing voice. 
To be more precise I have Application <---> Wireless Router <---> Asterisk 
<---> PSTN
So I think that is strange that could be an asterisk conversion problem, also 
because
incoming voice is perfect.

Have you got any ideas, or any test to do in order to find the problem?

Original comment by f.crisci...@gmail.com on 19 Nov 2009 at 2:41

GoogleCodeExporter commented 9 years ago
The problem MUST relate to the way sipdroid is encoding audio data. I did some 
more testing and found 
stuttering (outgoing only) anytime I cross borders from Voip to PSTN.  I will 
try again with pbxes and 
Comeback back again. 

Original comment by oakcam...@googlemail.com on 20 Nov 2009 at 7:31

GoogleCodeExporter commented 9 years ago
The problem MUST relate to the way sipdroid is encoding audio data. I did some 
more testing and found 
stuttering (outgoing only) anytime I cross borders from Voip to PSTN.  I will 
try again with pbxes and 
come. back again. 

Original comment by oakcam...@googlemail.com on 20 Nov 2009 at 7:31

GoogleCodeExporter commented 9 years ago
The problem MUST relate to the way sipdroid is encoding audio data. I did some 
more testing and found 
stuttering (outgoing only) anytime I cross borders from Voip to PSTN.  I will 
try again with pbxes and 
come. back again. 

Original comment by oakcam...@googlemail.com on 20 Nov 2009 at 7:32

GoogleCodeExporter commented 9 years ago
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:07

GoogleCodeExporter commented 9 years ago
I am also experiencing this problem.

Setup here is several different phone extensions peering over the local LAN and 
WiFi
to our Asterisk server.  Using SIPdroid on the Nexus One as one such extension. 
 The
Asterisk server then peers with an external PSTN gateway service.  Setup has 
been in
place and in use for years.  Only the SIPdroid extension is new.

Calls from non-SIPdroid extensions to/from external PSTN numbers work fine with 
good
audio both ways.

Calls from the SIPdroid extension to/from the same external PSTN numbers suffer
severe audio loss in the SIPdroid->PSTN direction.

Have tried using both the default alaw as well as forcing ulaw to the SIPdroid
phone... doesn't make any difference.  There's still audio loss in the SIPdroid
outbound direction.

Calls to/from the SIPdroid extension to another internal extension are fine, 
even
when the other internal extension is peering from a remote internet site.  The
problem appears only for calls to/from the PSTN gateway.

I am familiar with SIP and Asterisk debugging as well as firewalls, etc.  I 
will make
some time to look into this more.  However, if anyone has any thoughts or 
suggestions
as to where to look first, that might speed things up.

Original comment by jropal...@gmail.com on 11 Jan 2010 at 5:56

GoogleCodeExporter commented 9 years ago
Following up, I have managed to achieve significant (but not total) improvement 
by
enabling the Asterisk jitter buffer:

[general]
jbenable=yes
jbforce=yes

(This is available in Asterisk 1.4 and 1.6.)

As I said, I still experience some audio loss, but much, much less now.  It may 
be
possible to improve further using the jitter buffer parameters jbmaxsize,
jbresyncthreshold and jbimpl.

Original comment by jropal...@gmail.com on 12 Jan 2010 at 4:41

GoogleCodeExporter commented 9 years ago
Yet more testing gives better results with the following Asterisk config in 
sip.conf:

[general]
jbenable=yes
jbforce=yes
jbmaxsize=500
jbresyncthreshold=2500
jbimpl=adaptive

This causes Asterisk to create two jitterbuffers, one on each of its outbound 
audio
paths.

However, while the SIPdroid->PSTN audio path is now much improved, there is now 
some
choppiness on the PSTN->SIPdroid audio path.  It is sufficient to make the call
unintelligible for periods... enough to make one hang up and use another phone.

VoIP over UDP on an IP network is inherently jittery.  UDP datagrams can arrive 
late
or not at all.  SIP is designed to work in that environment.  It is up to each
receiving endpoint to adequately buffer and dejitter.

As I noted above in comment 18, I have operated this Asterisk server with a 
variety
of extensions (hard phones, soft phones and WiFi phones) for some years.  I 
have not
needed to use Asterisk's dejittering capability before.  In fact, Asterisk's
dejittering capability is really only intended for use when Asterisk terminates 
a
call onto a device that cannot handle jitter.  In the SIP-to-SIP case (as is 
the case
for SIPdroid to Asterisk to another SIP-based PSTN terminator) there is really 
no
point dejittering at Asterisk since the outbound path is very likely to incur 
further
jitter.

That is probably why using Asterisk's jitterbuffer helps but does not make 
things
perfect.

Since I have not had this problem with those other devices, this all points to
SIPdroid not adequately buffering datagrams and properly dealing with delayed
traffic.  Indeed, SIPdroid's call monitor is showing around 4% late during the
periods I still hear choppiness.

By comparison, another extension here is a UTStarCom F3000 WiFi phone.  Audio 
there
is 100% perfect in both directions and over prolonged calls - whether or not I 
have
Asterisk's jitterbuffer enabled.  So this shows that whatever is the cause of 
the UDP
delays (be it internet traffic to/from the PSTN terminator or perhaps local WiFi
radio noise), it is not enough to wreck the audio using that phone.  I have 
used both
the UTStarCom and SIPdroid on identical tests.

I am therefore leaning towards saying that SIPdroid, or perhaps the underlying
Andriod IP stack, has a severe problem with its buffer handling.

Original comment by jropal...@gmail.com on 12 Jan 2010 at 7:43

GoogleCodeExporter commented 9 years ago
Adding to the above, I have just found and tried SipAgent on the same Nexus One
phone.  SipAgent works perfectly - 100% good audio in both directions when on
SIP-Asterisk-SIP/PSTN terminator calls - and even without Asterisk's 
jitterbuffer
enabled.

Further indication that SIPdroid needs some attention to its RTP buffer 
handling.

Original comment by jropal...@gmail.com on 12 Jan 2010 at 11:38

GoogleCodeExporter commented 9 years ago
The issue described in <a
href="http://code.google.com/p/sipdroid/issues/detail?id=268">issue 268</a> may 
be
the same as I am experiencing here now for my incoming audio problems.

However, the separate issue on garbled outbound audio that is fixed by enabling
Asterisk's jitterbuffering still suggests a separate problem with SIPdroid to
Asterisk to a SIP-PSTN terminator.

Original comment by jropal...@gmail.com on 13 Jan 2010 at 10:02

GoogleCodeExporter commented 9 years ago
My incoming audio problem is, indeed, the same as issue 268.

My outbound audio problem, when calling via an Asterisk server, remains.

I note that the code in media/RtpStreamSender.java calls
AudioRecord.getMinBufferSize() to use a minimum record buffer size.  However, 
the
documentation for this method on developer.android.com suggests that that "size
doesn't guarantee a smooth recording under load, and higher values should be 
chosen
according to the expected frequency at which the AudioRecord instance will be 
polled
for new data."

Interestingly, SipAgent has recently introduced a configuration parameter for 
the
record buffer size, allowing the user to manually set a size.

I am not set up with an Android SDK environment.  Could I therefore ask for 
help from
one of the developers with this, please?  A useful first test would be to also
introduce a configurable record buffer size here too so that I can run some 
tests and
provide feedback regarding what buffer size solves this, if this is in fact the 
cause
of this problem.

Thanks.

Original comment by jropal...@gmail.com on 14 Jan 2010 at 9:27

GoogleCodeExporter commented 9 years ago
Possible solution... patch included...

Looking at the code in RtpStreamSender.java I see that the do_sync and sync_adj
variables exist but are never used.  This means that sender stream 
synchronization is
not actually implemented.

Lots of testing leads me to think that this problem is due to the phone sending 
data
in bursts rather than as periodic traffic.

The patch below is not intended as a final patch, but rather to demonstrate the
point.  It does significantly improve things.  With it, I can now send via 
Asterisk
to an outside SIP-based PSTN terminator with reasonable outbound audio quality 
even
without using the Asterisk jitterbuffer.  However, this also causes an Audio 
Error
pop-up on the phone a short while into the call, so clearly this needs more 
work.

The patch merely adds a short 20ms delay (because sync_adj is 2) between each
transmitted RTP datagram.  This changes the burstiness of transmitted traffic.

Any thoughts from someone more familiar with this code?  Any of the orginial
developers care to comment?

$ diff -u src/org/sipdroid/media/RtpStreamSender.java.orig
src/org/sipdroid/media/RtpStreamSender.java
--- src/org/sipdroid/media/RtpStreamSender.ojava        2010-01-18 
17:07:39.000000000
-0500
+++ src/org/sipdroid/media/RtpStreamSender.java 2010-01-18 17:11:33.000000000 
-0500
@@ -360,6 +360,12 @@
                                         ring = 0;
                                 }
                         }
+                       try {
+                               if (sync_adj > 0)
+                                       Thread.sleep(sync_adj * 10);
+                       } catch (Exception e) {
+                               e.printStackTrace();
+                       }
                }
                record.stop();

Original comment by jropal...@gmail.com on 18 Jan 2010 at 10:31

GoogleCodeExporter commented 9 years ago
Better patch...

This patch notes the system time of the last transmission and uses it to 
compute a
delay based on the frame_rate before the next transmission.

I had to change Thread.sleep() to just sleep() to avoid the Audio Problem error.

$ diff -u src/org/sipdroid/media/RtpStreamSender.ojava
src/org/sipdroid/media/RtpStreamSender.java
--- src/org/sipdroid/media/RtpStreamSender.ojava        2010-01-18 
17:07:39.000000000
-0500
+++ src/org/sipdroid/media/RtpStreamSender.java 2010-01-18 18:08:39.000000000 
-0500
@@ -245,6 +245,10 @@
                boolean improve =
PreferenceManager.getDefaultSharedPreferences(Receiver.mContext).getBoolean("imp
rove",false);
                boolean useGSM =
!PreferenceManager.getDefaultSharedPreferences(Receiver.mContext).getString("com
pression","edge").equals("never");
                int micgain = (int)(Settings.getMicGain()*10);
+               long frame_gap = 1000 / frame_rate;
+               long last_tx_time = 0;
+               long next_tx_delay;
+               long now;
                running = true;
                m = 1;

@@ -340,12 +344,20 @@
                         rtp_packet.setSequenceNumber(seqn++);
                         rtp_packet.setTimestamp(time);
                         rtp_packet.setPayloadLength(num);
+                        now = System.currentTimeMillis();
+                        next_tx_delay = frame_gap - (now - last_tx_time);
                         try {
+                                try {
+                                        if (next_tx_delay > 0)
+                                                sleep(next_tx_delay);
+                                } catch (InterruptedException e1) {
+                                }
                                 rtp_socket.send(rtp_packet);
                                 if (m == 2)
                                         rtp_socket.send(rtp_packet);
                         } catch (IOException e) {
                         }
+                        last_tx_time = System.currentTimeMillis();
                         time += frame_size;
                         if (improve && RtpStreamReceiver.good != 0 &&

RtpStreamReceiver.loss/RtpStreamReceiver.good > 0.01 &&

Original comment by jropal...@gmail.com on 18 Jan 2010 at 11:25

GoogleCodeExporter commented 9 years ago
I have tried the patch on an htc magic and on a Acer liquid and it achieves 
great 
result.
Now especially on the htc magic, there is a significant outgoing delay, but the 
phone 
call is well understandable.

Original comment by f.crisci...@gmail.com on 20 Jan 2010 at 4:59

GoogleCodeExporter commented 9 years ago
Can you please post the patched apk somewhere please?

Original comment by arnonse...@gmail.com on 20 Jan 2010 at 5:11

GoogleCodeExporter commented 9 years ago
here you are, it is signed with my key.

Original comment by f.crisci...@gmail.com on 20 Jan 2010 at 5:13

Attachments:

GoogleCodeExporter commented 9 years ago
The patch is not ready for release because of the outgoing delay it introduces.

Original comment by pmerl...@googlemail.com on 21 Jan 2010 at 2:22

GoogleCodeExporter commented 9 years ago
I do not believe at the moment that this patch is the cause of the delay 
mentioned
above.  In my own testing, there is a slight (0.5 sec) delay, but this delay is 
also
experienced without the patch.

The code in the patch delays an outgoing frame by up to 20ms only, given that 
the
frame_rate is fixed at 50/sec, and that delay is reduced to allow for time 
already
elapsed.  Such a delay is hardly likely to be noticeable.

If you still disagree with this patch, could you suggest another way that we 
might
control frame sending rates in order to minimize jitter?

Original comment by jropal...@gmail.com on 21 Jan 2010 at 3:22

GoogleCodeExporter commented 9 years ago
I agree with jropal, because on the acer liquid the delay is not significant. 
Now we 
are looking to find some other explanation about delay. 
It could be very useful if also people try the patched version on different 
devices, in 
order to understand well where is the delay problem.

Original comment by f.crisci...@gmail.com on 21 Jan 2010 at 7:42

GoogleCodeExporter commented 9 years ago
Here is a modified version of the patch.  In this version, I change the code 
flow from:
    read_audio()
    send_datagram()
to:
    if (last datagram sent < frame_period)
        sleep(until next period)
    read_audio()
    if (nothing read)
        continue
    send_datagram()

This means that (a) no datagram will be sent if the audio read returned nothing 
and
(b) the time between the audio read and the datagram transmission is exactly as 
it is
in the original code.

Enjoy...

--- src/org/sipdroid/media/RtpStreamSender.ojava        2010-01-21 
08:31:22.000000000
-0500
+++ src/org/sipdroid/media/RtpStreamSender.java 2010-01-21 08:58:00.000000000 
-0500
@@ -245,6 +245,10 @@
                boolean improve =
PreferenceManager.getDefaultSharedPreferences(Receiver.mContext).getBoolean("imp
rove",false);
                boolean useGSM =
!PreferenceManager.getDefaultSharedPreferences(Receiver.mContext).getString("com
pression","edge").equals("never");
                int micgain = (int)(Settings.getMicGain()*10);
+               long frame_period = 1000 / frame_rate;
+               long last_tx_time = 0;
+               long next_tx_delay;
+               long now;
                running = true;
                m = 1;

@@ -286,7 +290,16 @@
                                }
                                record.startRecording();
                         }
+                        now = System.currentTimeMillis();
+                        next_tx_delay = frame_period - (now - last_tx_time);
+                        try {
+                                if (next_tx_delay > 0)
+                                        sleep(next_tx_delay);
+                        } catch (InterruptedException e1) {
+                        }
                         num = record.read(lin,(ring+delay)%(frame_size*11),frame_size);
+                        if (num <= 0)
+                                continue;

                         if (RtpStreamReceiver.speakermode == AudioManager.MODE_NORMAL) {
                                 calc(lin,(ring+delay)%(frame_size*11),num);
@@ -346,6 +359,7 @@
                                         rtp_socket.send(rtp_packet);
                         } catch (IOException e) {
                         }
+                        last_tx_time = System.currentTimeMillis();
                         time += frame_size;
                         if (improve && RtpStreamReceiver.good != 0 &&

RtpStreamReceiver.loss/RtpStreamReceiver.good > 0.01 &&

Original comment by jropal...@gmail.com on 21 Jan 2010 at 2:23

GoogleCodeExporter commented 9 years ago
Here is an apk containing the above patch.  As the filename implies, it is 
based on
SIPdroid revision r424 plus the issue 69 comment 32 patch.  It is signed with 
the my
key... so you will need to uninstall the official version before you can 
install this
one.

The intent of this version is that folk using SIPdroid to an Asterisk server 
can make
calls to an outside SIP-to-PSTN terminator with good quality audio.

Feedback is appreciated.

Original comment by jropal...@gmail.com on 21 Jan 2010 at 5:10

Attachments:

GoogleCodeExporter commented 9 years ago
A small delay in receiving audio when calling from SIP to a PSTN phone is to be
expected.  If you test from your SIPdroid to your own home phone or another cell
phone, you should expect a delay.  Here's why...

It takes time for your SIP data to reach your Asterisk server and then reach the
SIP-to-PSTN terminator you are using.  In my case, ping round-trip-times from my
gateway to my PSTN terminator are about 90ms so about 45ms each way.  A few 
more ms
can be added for the local network transit time, so say 50ms.  The SIP-to-PSTN
service will then have to de-jitter... this buffering alone can add 100ms, 
200ms...
maybe as much as 500ms to the path as my observations above in comment 20 have 
shown.
 Then, the audio must travel over the PSTN network, through various trunks,
inter-carrier switches and over the termination network (your local phone wire, 
or
your cellular service's GSM network).  The time for this will depend on the 
distance
traveled and the complexities of the network interconnections and any 
congestion at
your GSM node.  It's not unlikely that hundreds of kilometers may be traveled 
for a
call from your WiFi network to your cell phone.  It would not surprise me to
experience 100-150ms for a landline and 250-400ms for a call to a cell phone.

Add these up, and you will see that 250ms at a minimum and 650ms or maybe even 
more
at the high end are to be expected.

A 250ms (i.e., quarter second) delay is not much of a problem in most 
conversations.
 500ms (half second) gets noticable, and much over 1sec gets annoying.

In my own testing, I am at the low end of this scale, even with the patch in 
comment 32.

Note that the audio going back from your landline/cellphone to your SIP phone 
will
not have as much delay.  That is because there is no de-jittering needed when 
going
from a plain audio stream to a packet stream.  Therefore the 100..200ms or more 
delay
from the de-jitter buffering is not present in the return path.

You can get a sense of de-jitter buffering delays at a SIP-to-PSTN terminator by
comparing the delays between your outbound and incoming audio streams.

Note that when you make calls through an Asterisk server, the SIP-to-PSTN 
terminator
used may be different on different calls depending on the Asterisk server's
configuration.  My own Asterisk server, for example, uses ENUM lookups and 
sends each
call to to whatever terminator accepts that number space.  Two services offer
termination of US toll-free numbers.  I have noticed that one of them does 
suffer
from slightly longer delays than the other.

Original comment by jropal...@gmail.com on 21 Jan 2010 at 6:06

GoogleCodeExporter commented 9 years ago
I don't think record.read ever returns 0. It should block instead.

Original comment by pmerl...@googlemail.com on 21 Jan 2010 at 8:49

GoogleCodeExporter commented 9 years ago
You may be correct, but it does not say that in the Android developer 
documentation,
so I cannot assume that conclusion.  In any case read() is documented to 
possibly
return error indicators which are also handled by the test in this patch.

Original comment by jropal...@gmail.com on 21 Jan 2010 at 9:16

GoogleCodeExporter commented 9 years ago
Further revision to this patch that reduces the delay.  The audio quality 
remains
good with Asterisk.  I hope that now this will be accepted.

The attached .apk is built from SIPdroid revision 425 plus this patch.

Original comment by jropal...@gmail.com on 23 Jan 2010 at 9:41

Attachments:

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
It works great! It resolves shuttering voice problem and also delay problem. If 
the 
patch is accepted, issue could be considered as resolved.
I have tested it on 3 different devices: htc magic, acer liquid and Archos 5, 
in all 
cases result is perfect.

Original comment by f.crisci...@gmail.com on 24 Jan 2010 at 7:01

GoogleCodeExporter commented 9 years ago
The problem I see is every time next_tx_delay < 0 the delay is raised by -
next_tx_delay. The longer the call the larger the delay gets. After a few 
minutes you 
will notice several seconds of delay.

Original comment by pmerl...@googlemail.com on 24 Jan 2010 at 11:04

GoogleCodeExporter commented 9 years ago
How so?

next_tx_delay is calculated each time as the difference between the current 
clock
time and the last time, and this is subtracted from the frame_period (which is 
20ms
since frame_rate is 50 frames per second).  At MOST, a frame can be delayed by 
20ms.
 In practice, since the transmit loop takes some time, that time will be taken off
the 20ms and actual delays will be less than 20ms.  Thus each frame will be 
sent 20ms
after the last one, as it should be.

Nowhere is the delay added to the last time's delay.

I have made quite a few calls using this patch now and, in practice, there is 
only a
very short delay (like 100ms or so for me) and this delay does not get longer 
as the
call goes on.  I have made some long (30 minute) calls, too, without noticing 
any
increase of the delay.

Is your comment a report from running this code, or are you saying this based 
on just
looking at the patch?

Original comment by jropal...@gmail.com on 24 Jan 2010 at 11:28

GoogleCodeExporter commented 9 years ago
I made some some calls too, two of them of about 20 minutes, and I did not have 
any 
delay problem.

Original comment by f.crisci...@gmail.com on 25 Jan 2010 at 6:52

GoogleCodeExporter commented 9 years ago
Here's a further update to the patch.  This adjusts last_tx_time appropriately 
if a
sleep is done.

I am having a hard time hearing the delay getting longer.  I have made more test
calls, but I have no empirical way of measuring if a delay is growing over a 
long
call.  I am having to test just by listening to calls from one phone to 
another. 
After 30 and 45 minute calls, it is hard to know if the delay now is the same as
before or if it is longer.  If it IS longer, it is certainly not much longer for
me... less than 100-200ms - 1/10th to 1/5th sec.

If this delay is, indeed, getting longer, I'd think it would have to be because 
the
rate we're sampling AudioRecord is not the same as the RTP transmission rate.

The frame rate is set (in JAudioLauncher.java) to 50 frames/sec, and I am using 
that
to calculate the RTP transmission period of 20ms.

My assumption is that AudioRecord records continuously and gives you what data 
it has
when you read() it.  Correct?

If so, read()ing AudioRecord too often will result in more frames per second 
than
your desired frame rate.

By using code like this patch to gate the reads at one every frame_period, the 
reads
should be synchronized with the RTP transmissions, shouldn't they?

If not, why not?

We HAVE to solve this.  The app without this patch is useless with an Asterisk 
server
- the audio remains very choppy, broken up and unintelligible.  With this patch 
it is
clear and usable.  But if we are adding a delay, we need to figure out why and 
solve
that, too.

Original comment by jropal...@gmail.com on 25 Jan 2010 at 7:13

Attachments:

GoogleCodeExporter commented 9 years ago
You're right. Patch is accepted. Welcome as a project member!

Original comment by pmerl...@googlemail.com on 25 Jan 2010 at 1:28

GoogleCodeExporter commented 9 years ago
Thank you and thanks also for adding me as a member.

Should I commit this patch, or will you?

Original comment by jropal...@gmail.com on 25 Jan 2010 at 5:30

GoogleCodeExporter commented 9 years ago
You commit it.

Original comment by pmerl...@googlemail.com on 26 Jan 2010 at 1:23

GoogleCodeExporter commented 9 years ago
I slightly modified your patch to take care of the delay problem.

Original comment by pmerl...@googlemail.com on 27 Jan 2010 at 10:54

GoogleCodeExporter commented 9 years ago
OK on the frame_size check.

On subtracting 1 millisecond from the last_tx_time... maybe we should subtract
sync_adj instead?  It is initialized to 2ms in JAudioLauncher.java.  Or use 
sync_adj
and set it to 1 if that value works.

Original comment by jropal...@gmail.com on 27 Jan 2010 at 3:59

GoogleCodeExporter commented 9 years ago
Yes, I thought 2ms would be better, too. Change it to sync_adj. Good idea!

Original comment by pmerl...@googlemail.com on 27 Jan 2010 at 8:23