[Freeswitch-users] Conference timer synchronization with T1 FreeTDM - how?

[Anthony Minessale]

On Wed, Sep 25, 2013 at 7:36 AM, Bob Hartwig
<bobjectsfreeswitch at gmail.com>wrote:

> Hello Anthony,
>
> On Tue, Sep 24, 2013 at 11:45 PM, Anthony Minessale <
> anthony.minessale at gmail.com> wrote:
>
>> You could test your theory more by making an extension like this:
>>
>>     <extension name="test">
>>       <condition field="destination_number" expression="^1234$">
>>         <action application="answer"/>
>>         <action application="set" data="time_name=soft"/>
>>         <action application="playback"
>> data="tone_stream://%(251,0,1004);loops=-1"/>
>>       </condition>
>>     </extension>
>>
>>
>> This would produce a timer and use it for playback instead of the read
>> stream.
>>
>>
> Yes, I did just that yesterday, and the playback is similarly distorted
> then.  That experiment is what made me pretty certain that the
> mod_conference timer was my culprit.
>
>
>
>
>> If you wanted to make a timer you could use from the TDM you would have
>> to make a FS module with raw dahdi code in it that opened a socket and
>> clocked off of it and pushed it out to the channels like how some of the
>> other timer modules do but I think if you are on a modern kernel with
>> timerfd that this should not be necessary.  If you are on an older platform
>> like centos5 you could try the old -heavy-timer command line arg.
>>
>>
> -heavy-timer is new to me, thanks for the tip.  My problem is not timer
> accuracy, but timer synchronization with the T1 clock.  But grepping for
> heavy-timer may give me some insight on how to replace the main timer if it
> turns out that I need to go that way.
>
>     Thanks,
>     Bob
>
>
Not replace the main timer ...., we have timer modules you can create and
configure.  I gave you the recipe above.
You didn't note the distro really.

One more warning, dahdi runs at 1000hz internally because it's paranoid
that it won't accurately catch the 8000hz.  Asterisk and all of its
satellites like zaptel/dahdi etc always ran on a notion of using the read
stream to clock the write.  It would be really nice if you could reproduce
this issue on a Sangoma setup to rule out every moving part we don't
control between FreeTDM and your T1 line.  I know Sangoma did a lot of work
inspired by ClueCon 1 to produce slower interrupt timing sync.

I'm sure you could find someone to run the test for you on other boxes from
the extension I pasted above and see if the problem is reproducible
elsewhere.










>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130925/98d0709f/attachment.html