Incoming PSTN calls very quiet

Recently set up a new FreePBX box with one incoming FXO and one incoming BRI. So a total of three incoming channels.

For some reason incoming (rx) is really (really…) quiet on the pstn line, and increasing the global rxgain is not doing helping. I have also tried setting the hwgain using the Asterisk CLI but I’m not having any luck.
The gain does seem to be making a difference to the BRI though, even though I have set specific gain settings for that BRI card…

This is with an OpenVox FDM400 card.



; generated by module
#include chan_dahdi_general.conf

; for user additions not provided by module
#include chan_dahdi_general_custom.conf


; for user additions not provided by module
#include chan_dahdi_channels_custom.conf

; include dahdi groups defined by DAHDI module of FreePBX
#include chan_dahdi_groups.conf

; include dahdi extensions defined in FreePBX
#include chan_dahdi_additional.conf

Any help would be much appreciated.

Thanks! :slight_smile:

Correct me if I am wrong but those parameters are only for analog cards.

There is no gain in a digital signal, it’s either TTL or lower in voltage. The volume of the sound is controlled by the bit positions. The farther you shift to the right (increase the value) of the most significant digits you will double the volume (10dbv analog equivalent) (also in assembly language rotate right through carry) so the only analog portion in the signal chain is your handset or softphone. From a gain staging standpoint that is the only place to tweak and why phones have volume controls. Because transmission does not degrade a digital signal there is no loss through the network or the Digium car hence no reason to alter the already quantitized analog bit stream.

I am sure this makes your head hurt but I wanted you to know that in know way does a digital telephony interface alter the level of the sound.

And correct me if I am wrong also, but the TX/RX gains should be applied AFTER all the digital framing etc. on the B channel extracts the audio, it is after all g711 and many providers just do not “normalize” the audio, here I often see Verizon fios boxes being misconfigured by plus or minus up to 12db or more. (I noticed that the installer doesn’t normally have a butt set anymore, so how would they know? and when you tell them the explicit problem, they look at you blankly . . . :wink: )

( I suggest the OP goes back to the good old “dahdi_monitor -vv route”, changing TX/RX, restarting dahdi . . . the milliwatt() app still is king as to balancing the line.)

I am not sure I understand the FiOS reference. That is nothing more than an h.323 gateway. I am sure they can adjust the levels but they don’t train techs prescription levels and impedance matching. When is the last time you some a phone guy with an analog meter around his neck that could check a pair. Lost skills.

In his case the B channel PCM will go to the Asterisk “mixer” and get transcoded to whatever CODEC the endpoint is. Levels don’t change. Dynamic range and frequency response can be altered by a lossy CODEC but not level within the low dynamic range of a 3Khz phone channel. If the S/N ration is 45db that only leaves a delta of 25db for dynamic range (the difference between the loudest and softest discernable content).

Thanks for referring me to dahdi_monitor. When the line rings it maxes out, which is what I would expect, but once I answer it only moves a tiny amount. The rx doesn’t really get past 400 and it is so quiet you can’t make anything out.

This is with rx set to 12dB and tx set to 3dB (but tx is fine), so it seems to me that this setting is being ignored.

I have tried turning off echo cancellation, it doesn’t make any difference to the volume but does result in a little echo on other lines.

I recompiled Dahdi using the version provided by OpenVox. At first, everything broke and I was sweating. But then I fixed it some how and now the tx/rx gain settings are actually doing something, instead of just taking up disk space.

Thanks anyway, guys. :slight_smile:

Glad you got it working, given the vagaries of some providers and indeed hardware, IMHO it is one of the first things that should be tuned on any new system, just use milliwatt() locally and a milliwatt test number externally, bridge the legs and balance them , Echo Cancellation , software or hardware, will ALWAYS converge better if you do that, it’s just basic math , (the same math that the Fast Furier Transforms’s used by by all echo cancellation techniques, you just make it easier by following that simple step.)

(just to be complete, “on any new system with analog or TDM technology”, it has no effect on VOIP trunking)