[asterisk-dev] patlooptest tool on DAHDI

[Marco Signorini]

Shaun Ruffell wrote:
> 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.
>
>   

Thank you. This really makes it better.
Rising the patlooptest process to real-time priority lets me able to
terminate some 60 seconds and one 300 seconds length tests with no
errors. This, also, explains why there are less errors when redirecting
the standard output to a file, being the process faster then writing to
the console.

Thank you very much, Ruffel, you saved me a lot of time and troubles.

Best regards,
Marco Signorini

=======================
INGEGNI Tech S.r.l.
http://www.ingegnitech.com