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

On Tue, Sep 24, 2013 at 11:45 PM, Anthony Minessale <anthony.minessale@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900