I tried it with the latest trunk. If I set it to 60ms sometimes I still get <1ms rtp packet delta, if I set it to 120ms then there is none 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. Anthony Minessale wrote:
Have you tried setting the codec-ms in the portaudio.conf.xml to 60 or 120 ms? Maybe the soundcard is not able to do 20ms intervals and portaudio is doing the least common multiple and chopping it up for us. 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:
20ms (timeout..... flush buffer) 20ms (timeout..... flush buffer) 20ms (get 60ms worth of audio at once [3 20ms packets] but we have already read 2 filler frames from the timeouts)
So now we have read 5 packets instead of 3 and erased some of our buffer because of perceived timeouts. The code is using the assumption that if the device will obey the chosen frame size and sample rate requests down to the interval.
If you find and edit conf/autoload_configs/portaudio.conf.xml
look for this:
<param name="codec-ms" value="20"/>
and change 20 to 60
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 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.
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.
The same should be true for setting the codec-ms to 120
On Wed, May 7, 2008 at 3:27 AM, Sluschny, Thomas <Thomas.Sluschny@siemens.com <mailto:Thomas.Sluschny@siemens.com>> wrote:
Hi Anthony,
i also tested your patch with no success. As i already described below, the problem with all 60ms 3 packets comes from the soundcard. The hardware delivers its samples all 60 ms. Our problem is (like Csaba said) that we read out the buffer after 60ms, 3 times, each with samples for 20ms, AND WITH NO DELAY! 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.
In my patch i wait appr.20 ms if last method call was no longer than 4ms ago, but i think we can do better with switch_core_timer_check() method, but i don't know exactly how.
You are absolutly right with your demand for a better timing resolution under Windows, but this 60ms mystery is caused by the soundcard.
Thomas
------------------------------------------------------------------------