<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I tried it with the latest trunk.<br>
If I set it to 60ms sometimes I still get <1ms rtp packet delta, if
I set it to 120ms then there is none<br>
The rtp packet delta is still random within 50-70ms with sometimes too
low 15-30ms, sometimes too high 100-150ms delta (with codec-ms = 60ms),
and with 15-20ms jitter.<br>
<br>
<br>
Anthony Minessale wrote:
<blockquote
cite="mid:191c3a030805070618m3d4ef8e2i8033588a2db83aa4@mail.gmail.com"
type="cite">Have you tried setting the codec-ms in the
portaudio.conf.xml to 60 or 120 ms?<br>
Maybe the soundcard is not able to do 20ms intervals and portaudio is
doing the least common multiple and chopping it up for us.<br>
I think what's happening is the timer in the module is set to the
interval from the config file (20ms) and during every 60ms period there
is no audio until the last ms. so in each 60 ms:<br>
<br>
20ms (timeout..... flush buffer)<br>
20ms (timeout..... flush buffer)<br>
20ms (get 60ms worth of audio at once [3 20ms packets] but we have
already read 2 filler frames from the timeouts)<br>
<br>
So now we have read 5 packets instead of 3 and erased some of our
buffer because of perceived timeouts.<br>
The code is using the assumption that if the device will obey the
chosen frame size and sample rate requests down to the interval.<br>
<br>
If you find and edit conf/autoload_configs/portaudio.conf.xml<br>
<br>
look for this:<br>
<br>
<param name="codec-ms" value="20"/><br>
<br>
and change 20 to 60<br>
<br>
Setting this to 60 will change the frame size of all the packets from
320 to 960 and set the timer to clock at an interval of 60ms<br>
Since the card seems to be able to reliably produce 3 20ms packets
every 60ms it should also be able to produce 1 60ms packet.<br>
<br>
FreeSWITCH should then buffer the audio and still deliver it over SIP
at 20ms if you want but you can opt to set the codec PCMU@60i to
disable buffering if you are in a reliable network.<br>
<br>
The same should be true for setting the codec-ms to 120<br>
<br>
<br>
<div class="gmail_quote">On Wed, May 7, 2008 at 3:27 AM, Sluschny,
Thomas <<a moz-do-not-send="true"
href="mailto:Thomas.Sluschny@siemens.com">Thomas.Sluschny@siemens.com</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2">Hi Anthony,</font></span></div>
<div dir="ltr" align="left"><span></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2">i also tested your patch with no success.</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2">As i already described below, the problem with all 60ms 3
packets comes from the soundcard.</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2">The hardware delivers its samples all 60 ms.</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2">Our problem is (like <font face="Times New Roman" size="3">Csaba
said</font>) that we read out the buffer after 60ms, 3 times, each with
samples for 20ms, AND WITH NO DELAY!</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2">So we get: 60ms wait and 3 RTP packets within <1ms to
send, and after that we already wait 60 ms for the next samples.</font></span></div>
<div dir="ltr" align="left"><span></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2">In my patch i wait appr.20 ms if last method call was no
longer than 4ms ago,</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2">but i think we can do better with switch_core_timer_check<span>()
method, but i don't know exactly how.</span></font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2"><span></span></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2"><span>You are absolutly right with your demand for a better
timing resolution under Windows,</span></font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2"><span>but this 60ms mystery is caused by the soundcard.</span></font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2"><span></span></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial"
size="2"><span>Thomas</span></font></span></div>
<br>
<div dir="ltr" align="left" lang="de">
<hr></div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>