[asterisk-dev] patlooptest tool on DAHDI

[Shaun Ruffell]

Marco Signorini wrote:
> Hi All,
> 
> I've recently installed a TE121P on a server. Before going in production
> I would like to test the card. I found the patlooptest tool in latest
> 2.1.0.2 DAHDI snapshot and I tried to run it following the suggestions
> found on Digium website http://kb.digium.com/entry/138/
> Running the tool I've a lot of errors. I tried to understand what
> happens and I found something strange on the patlooptest I can't understand.
> The tool skips the first 10 packets then starts to analyze what is
> received. The tool assumes that at the beginning of the 10th packet
> there will be something good. For what I can see dumping the packets my
> board receives, this is not always true: sometimes the packets to
> discard are less than 10, sometime more than 10.
> 
> So I've modified the code adding two functions: the first one adds a
> signature (four bytes 0x55AA55AA) to the first packet sent; the second
> one recognize this signature inside received packets and returns the
> byte offset where the signature ends. The tool will discard all received
> packets until a valid signature is found, then it will start to analyze
> all incoming packets. I've attached the code to this e-mail.
> 
> With these modifications I think I'm now able to find the beginning of
> the stream. Unfortunately I still have troubles. On some received packet
> there are burst values filled with 0xFF. I don't understand what I'm
> doing wrong and, for this reason, I ask to someone know better the DAHDI
> subsystem to help me to understand if there is something wrong with my
> board and/or server and, of course if required, to help me to fix the
> patlooptest tool.

You might not be doing anything wrong.  Clear channels that are not in 
audio mode (like those that are typically found when running 
patlooptest) will insert 0xff into the data stream when there aren't any 
buffers available from userspace.  i.e., the patlooptest user process is 
unable to keep up with the hardware due to some other system activity.

Here is the section from __dahdi_getbuf_chunk where the 0xff are inserted:

  } else if (ms->flags & DAHDI_FLAG_CLEAR) {
    /* Clear channels that are idle in audio mode need
       to send silence; in non-audio mode, always send 0xff
       so stupid switches won't consider the channel active
    */
    if (ms->flags & DAHDI_FLAG_AUDIO) {
      memset(txb, DAHDI_LIN2X(0, ms), bytes);
    } else {
      memset(txb, 0xFF, bytes);
    }
    bytes = 0;
}

Try running 'chrt -f 99 ./patlooptest /dev/dahdi/1' and see if your 
results are different.  This will make sure patlooptest is running in a 
real-time priority class.

> 
> I'm using DAHDI 2.1.0.4 on OpenSuse 11.1 and the board TE121B (with echo
> can onboard). The configuration I've is set to E1 mode.
> 
> What I'm missing?? Is there someone would help me, please?
> 

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
jabber: sruffell at digium.com
Check us out at: www.digium.com & www.asterisk.org