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

[Anthony Minessale]

do you have any other sound hardware like a usb headset or anything you can
compare it to.  I really would like to know if that sound card sucks or
something because I never see this in any of the stuff i am testing.

I can't even lab it up to try to fix.


On Wed, May 7, 2008 at 9:46 AM, Csaba Zelei <csaba.zelei at gmail.com> wrote:

>  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> 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
> >
> >  ------------------------------
> >
>
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20080507/8dda624b/attachment-0002.html