“scratchy” sound on TE410P

Home » Asterisk Users » “scratchy” sound on TE410P
Asterisk Users 15 Comments

asterisk 1.4.35
one span on a 4port T1 card

Got complaints this morning that outbound and inbound calls were
“scratchy” and I made a few test calls. It kind of sounds like the gain
is too high somewhere, and the audio is overdriven. Is this a problem at
the carrier? I’m trying to call them now, but it’s Sunday morning in the
sticks, and my chances of getting someone with a clue are slim to none.

I restarted dahdi but that had no effect.

I watched dahdi_tool as calls came in and out but there isn’t really a lot
of information there.

Sangoma has a cool tool “wanpipemon” that shows error stats and such on
the span. Is there such a tool for Digium cards?

Any suggestions?


15 thoughts on - “scratchy” sound on TE410P

  • dahdi_maint -s will provide the error counters that are
    available for the span. i.e.:

    ]# ./dahdi_maint -s 1
    Span 1:

    You can see verify if the drivers are adjusting the gain on a channel
    with the dahdi_diag tool. ‘make dahdi_diag’ in dahdi_tools in order to
    build it, since it’s not built by default. Then:

    ‘]# dmesg -c > /dev/null && ./dahdi_diag 1 && dmesg -c’

    And look for the gainalloc output to see if DAHDI is gaining the channels.


  • It could be the echo canceller, I had this kind of problem with OSLEC. I
    also thought the PRI provider was sending clipped audio. I switched to
    the VPM450 daughterboard and since audio has been crystal clear. What is
    your setup for echo cancelling?

  • I inherited this board, and don’t think it has the echo canceller
    daughterboard. Is there a way to query for it without taking the machine
    down? It is loading MG2 otherwise.

    Using dahdi_maint -s 1 I am tracking a lot of errors, anyway, so have the
    carrier taking a look this afternoon.



  • ‘dmesg | grep VPM’ should tell you if you have a hardware echo can installed
    and activating.

  • My problem seemed to be OSLEC specific (Debian stable with zaptel),
    switching to MG2 made my problems dissapear but overall voice quality is
    lower IMHO. You could try disabling ec all together and check if
    clipping still occurs. But it does sound like an operator problem if you
    get errors.

  • So it did in fact turn out to be a problem with the link itself. The
    carrier switched line pairs somewhere upstream and everything was back to
    normal. I am curious about the tool “dahdi_maint”… what do the various
    acronyms stand for? I tried to communicate with the line tech the errors
    I was seeing accumulate (the first four and the last one), but the
    acronyms didn’t mean anything to him. Are they standard telco stuff? I
    reset them after the line repair, and one is still accumulating, though
    very slowly. The “76” is over 24 hours.

    root@vigw3:/etc/asterisk# dahdi_maint -s 1
    Span 1:



  • Yea there seemed to be a bit of confusion here as well so I patched
    trunk with some more descriptive error counter labels :O)

    Framing Errors

    CRC Errors

    Code Violations

    E-Bit Counter

    Both of these were removed due to stale code

    General Errored Seconds

    Was this output a snapshot of your current system. Do you really have
    zeroed counters everywhere, but 76 errored seconds? If so, I’ll probably
    need to investigate.

  • Nice! Perfect.

    Yes, this is a snapshot after about 24 hours since I cleared the counters.
    I see what you mean – how can I have 76 seconds of errors but no bumped
    error counters. I ran again just now:

    root@vigw3:/etc/asterisk# dahdi_maint -s 1
    Span 1:

    Here’s to hoping that the error in error is the GES, and that actually I
    have no errors 😉



  • I seem to be having the same problem with a new server. I am using a
    TE220 with a VPM450 module. Using Dahdi 2.4.0 and Asterisk on
    a Dell server. All calls to the outside have bad voice quality (echo
    and distortion). Internal calls between extensions sound fine.

    Dahdi_main for Span 2 (20 days uptime).

    Span 2:

    Span 2: TE2/0/2 “T2XXP (PCI) Card 0 Span 2” (MASTER) HDB3/CCS
    Timing slips: 1566

    32 TE2/0/2/1 Clear (In use) (EC: VPM450M)
    33 TE2/0/2/2 Clear (In use) (EC: VPM450M)
    34 TE2/0/2/3 Clear (In use)
    35 TE2/0/2/4 Clear (In use)
    36 TE2/0/2/5 Clear (In use)
    37 TE2/0/2/6 Clear (In use)
    38 TE2/0/2/7 Clear (In use)
    39 TE2/0/2/8 Clear (In use)
    40 TE2/0/2/9 Clear (In use)
    41 TE2/0/2/10 Clear (In use)
    42 TE2/0/2/11 Clear (In use)
    43 TE2/0/2/12 Clear (In use)
    44 TE2/0/2/13 Clear (In use)
    45 TE2/0/2/14 Clear (In use)
    46 TE2/0/2/15 Clear (In use)
    47 TE2/0/2/16 HDLCFCS (In use)
    48 TE2/0/2/17 Clear (In use)
    49 TE2/0/2/18 Clear (In use)
    50 TE2/0/2/19 Clear (In use)
    51 TE2/0/2/20 Clear (In use)
    52 TE2/0/2/21 Clear (In use)
    53 TE2/0/2/22 Clear (In use)
    54 TE2/0/2/23 Clear (In use)
    55 TE2/0/2/24 Clear (In use)
    56 TE2/0/2/25 Clear (In use)
    57 TE2/0/2/26 Clear (In use)
    58 TE2/0/2/27 Clear (In use)
    59 TE2/0/2/28 Clear (In use)
    60 TE2/0/2/29 Clear (In use)
    61 TE2/0/2/30 Clear (In use)
    62 TE2/0/2/31 Clear (In use)

    We are using span 2 at the moment because span 1 is reserved for
    another E1 that will be connected soon.

  • On Thu, 11 Nov 2010 20:08:09 -0600, Russ Meyerriecks wrote

    Here it is.
    # Span 1: TE2/0/1 “T2XXP (PCI) Card 0 Span 1”

    # Span 2: TE2/0/2 “T2XXP (PCI) Card 0 Span 2” (MASTER)
    # termtype: te

    loadzone = mx
    defaultzone = mx

  • I have a hunch your Errored Seconds are incrementing due to the
    timing slips. But it looks like you’re configured to recover timing from
    the line properly. I’m uncertain as to what could cause this beyond a
    jittery trunk. The framing errors give evidence to support something is
    wrong with the trunk, as well.

    It might be worth getting with your service provider and running some
    loopback tests. You can put your digium card in a network facing
    loopback by using dahdi_maint as such:

    dahdi_maint -s 2 –loopback networkline

    This will allow your telco to run patterns towards your connection, for
    a while, to determine if there are any errors.

  • Sure thing:

    root@vigw3:/etc/asterisk# cat /proc/dahdi/1
    Span 1: TE4/0/1 “T4XXP (PCI) Card 0 Span 1” (MASTER) B8ZS/ESF

    1 TE4/0/1/1 E&M (In use) (SWEC: MG2) (EC: MG2)
    2 TE4/0/1/2 E&M (In use) (SWEC: MG2) (EC: MG2)
    3 TE4/0/1/3 E&M (In use) (SWEC: MG2) (EC: MG2)
    4 TE4/0/1/4 E&M (In use) (SWEC: MG2) (EC: MG2)
    5 TE4/0/1/5 E&M (In use) (SWEC: MG2) (EC: MG2)
    6 TE4/0/1/6 E&M (In use) (SWEC: MG2)
    7 TE4/0/1/7 E&M (In use) (SWEC: MG2)
    8 TE4/0/1/8 E&M (In use) (SWEC: MG2) (EC: MG2)
    9 TE4/0/1/9 E&M (In use) (SWEC: MG2)
    10 TE4/0/1/10 E&M (In use) (SWEC: MG2)
    11 TE4/0/1/11 E&M (In use) (SWEC: MG2)
    12 TE4/0/1/12 E&M (In use) (SWEC: MG2)
    13 TE4/0/1/13 E&M (In use) (SWEC: MG2)
    14 TE4/0/1/14 E&M (In use) (SWEC: MG2)
    15 TE4/0/1/15 E&M (In use) (SWEC: MG2)
    16 TE4/0/1/16 E&M (In use) (SWEC: MG2)
    17 TE4/0/1/17 E&M (In use) (SWEC: MG2)
    18 TE4/0/1/18 E&M (In use) (SWEC: MG2)
    19 TE4/0/1/19 E&M (In use) (SWEC: MG2)
    20 TE4/0/1/20 E&M (In use) (SWEC: MG2)
    21 TE4/0/1/21 E&M (In use) (SWEC: MG2)
    22 TE4/0/1/22 E&M (In use) (SWEC: MG2)
    23 TE4/0/1/23 E&M (In use) (SWEC: MG2)
    24 TE4/0/1/24 E&M (SWEC: MG2)

    and it is still incrementing…

    root@vigw3:/etc/asterisk# dahdi_maint -s 1
    Span 1:



  • Jeff,
    Hmm, I was expecting to see timing slips here. It looks like the
    framer is reporting something through GES that isn’t exported elsewhere.
    I’ll need to dig around for a bit to find it. You aren’t having any
    audio quality issues are you?