[Freeswitch-users] mod_portaudio send 3 rtppacket/60msinsteadof1 packet/20ms

[Csaba Zelei]

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 at 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 at siemens.com <mailto:Thomas.Sluschny at 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
>
>     ------------------------------------------------------------------------
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20080507/b4b76202/attachment-0002.html