[asterisk-users] 1.6.1 + TDM840 FSK MWI problem

[Barry Miller]

On Thu, Sep 10, 2009 at 05:06:01PM -0500, Doug Bailey wrote:
> 
> ----- "Doug Bailey" <dbailey at digium.com> wrote:
> 
> > ----- "Doug Bailey" <dbailey at digium.com> wrote:
> > 
> > > ----- "Barry Miller" <asterisk-users at notanet.net> wrote:
> > > 
> > > > On Fri, Sep 04, 2009 at 04:10:43PM -0500, Doug Bailey wrote:
> > > > > > > ----- "Barry Miller" <asterisk-users at notanet.net> wrote:
> > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > Using 1.4.26.1 & DAHDI 2.2.0.2, FSK VMWI devices off a
> > > TDM840
> > > > > > work
> > > > > > > > fine.
> > > > > > > > 
> > > > > > > > With 1.6.1.[45] & same DAHDI, instead of the FSK spill I
> > > get
> > > > a
> > > > > > line
> > > > > > > > polarity reversal.  Stutter dialtone is generated as
> > > > expected.
> > > > > > > > 
> > > > > > > > Has anyone else seen this?  Is there anything special I
> > > need
> > > > to
> > > > > > do
> > > > > > > > for
> > > > > > > > 1.6.1 to make FSK MWI work?
> > > > 
> > > >     [snip]
> > > > 
> > > > > 
> > > > > The only thing I can think of that would be preventing the
> > output
> > > > would be 
> > > > > problems in the interface chip with the On-Hook transfer mode. 
> > > > > 
> > > > > If you run a dahdi_monitor on the channel that should be
> > sending
> > > the
> > > > FSK 
> > > > > spill and look at the results in a program like audacity, you
> > can
> > > > see if 
> > > > > the MWI FSK spill is actually reaching the interface SLIC IC. 
> > > > > 
> > > > > Something like "dahdi_monitor 1 -t spilloutput.raw" (Monitors
> > the
> > > > output 
> > > > > going to dahdi channel 1.) 
> > > > 
> > > > Hmm.  With both 1.4 & 1.6, without touching
> > /etc/[asterisk|dahdi],
> > > > I used a butt-set to go off-hook, then back on.  I got:
> > > > 
> > > > 1.4.26.1:  dahdi_monitor captured stutter dialtone, 4.5 seconds
> > of
> > > >     silence, then the FSK spill.  And that's what I heard.
> > > > 
> > > > 1.6.1.6:   dahdi_monitor captured stutter dialtone, 1.5 seconds
> > of
> > > >     silence, then the FSK spill.  Sounds good with audacity.  But
> > > >     all I heard through the butt-in was stutter dialtone.  No FSK
> > > >     spill at all.
> > > > 
> > > > Here's hoping this tells you more than it does me :)
> > > > 
> > > Actually it does tell me a lot.  
> > > 
> > > The problem appears in how the interface chip is being programmed. 
> > 
> > > For some reason, the interface chip is not being set to on-hook 
> > > transfer mode which would allow for the mwi spill to go out on the 
> > > actual fxs port lines.  
> > > 
> > > I am looking to see where the problem lies. (It is either in
> > > chan_dahdi 
> > > or in the driver.)   I hope to have more information later. 
> > > 
> > 
> > The problem lies in a race condition between chan_dahdi making an
> > ioctl call to
> > set the VMWI state (performed in the do_monitor loop ) and a a
> > subsequent call
> > to set the channel in ONHOOK transfer mode (performed in
> > mwi_send_init).  This
> > requires the driver to send successive commands to the SLIC interface
> > chip
> > linefeed register.  If the command required for the VMWI mode is not
> > completed
> > by the time the ONHOOK transfer mode is requested, the ONHOOK transfer
> > request
> > is thrown away and the MWI spill does not get sent.
> > 
> > I will be fixing this in the drivers trunk branch and hope to have it
> > committed
> > soon.  I'm not sure when it will be released.
> > 
> > Another option is to comment out the ioctl call for VMWI in the
> > do_monitor loop
> > (especially if you do not care about line reversal MWI.).  
> > 
> 
> See https://issues.asterisk.org/view.php?id=15875 for more information

Thanks much!  I would not have figured that out.  Eliminating the ioctl
works fine for now-- rpas is not an issue here.

--Barry