GoogleCodeExporter
commented
8 years ago Original comment by pmerl...@googlemail.com on 10 Jul 2009 at 4:23
- Changed state: Duplicate
Closed GoogleCodeExporter closed 8 years ago
GoogleCodeExporter
commented
8 years ago Original comment by pmerl...@googlemail.com on 10 Jul 2009 at 4:23
GoogleCodeExporter
commented
8 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 stutterOriginal comment by nate.bar...@gmail.com on 20 Jul 2009 at 5:23
GoogleCodeExporter
commented
8 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
8 years ago [deleted comment]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
8 years ago Original comment by pmerl...@googlemail.com on 12 Oct 2009 at 6:58
GoogleCodeExporter
commented
8 years ago [deleted comment]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
8 years ago [deleted comment][deleted comment]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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 years ago [deleted comment]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
8 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
8 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
8 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
8 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
8 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
8 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
8 years ago You commit it.Original comment by pmerl...@googlemail.com on 26 Jan 2010 at 1:23
GoogleCodeExporter
commented
8 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
8 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
8 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
Original issue reported on code.google.com by
arnonse...@gmail.comon 10 Jul 2009 at 4:19