I am experiencing clicking or tapping noise with Digium TDM400P card. I have tried several setting on tx & rx gains with no luck. I even disabled echotraining like digium site said to remove tapping, but didn’t work either. It works perfectly between local extensions, problem only occurs when dialing external. If anyone has any suggestions it would be greatly appreciated.
I’m gettingth exact same problem with a TDM24xxxp. When I disable echocancel the sound is ok but i’m getting echo of myself on my polycom phone.
Have you been able to get ride of this ?
I’ve seen a post like this before. I have had this problem once, and I rebooted the server. It went away. My system was working properly previously. I hope your problem is this simple.
I am running a Dell Poweredge SC430 server with a TDM2400 (8 fxo 4 fxs). With both Polycom Soundpoint 320and Grandstream GXP-2000 using the latest firmware. Both have horrible sound (extremely low volume on the ear piece, static if amplified, fuzz and echo) going out or into the building at the handset. The outside world does not hear the problems. The TDM2400 is three feet from the demark. An analog phone (really cheap) doesn’t show these issues when connected direct to the POTS lines.
Running Asterisk 1.2.21.1 and zaptel 1.2.18; 20 phones total with 2/3 polycom. I have used fxotune with the fxotune_5.patch. I have tried kb1 and MG2 and Mark2 (best of the bunch). I have tuned using the ./fxotune -i2 with the local silent telco phone number. Echo reported with fxotune after tuning is below 4% for all 7 POTS lines.
fxotune.conf:
1=5,1,248,252,4,253,1,0,0
2=6,0,0,0,0,0,0,0,0
3=5,252,250,1,1,254,0,255,255
4=5,252,250,1,1,254,0,255,0
5=5,252,250,0,0,254,0,255,0
6=5,252,250,0,0,254,0,255,0
7=5,1,248,252,4,253,1,0,0
8=0,0,0,0,0,0,0,0,0
Summary:
~Inbound/Outbound calls have low volume, echo, dropped bits and fuzz at Soundpoint 320 or GPX-2000 handsets, outside world hears no issues. SIP <-> ZAP, SIP has problems, ZAP sounds great.
~TDM2400 has echo cancel chip
~FXOTUNE has been patched and run
~Different echo cancelers have been used in zconfig.h
~PBX is three feet from inside demark
~Brand new wiring at most phone connections; home run for each Polycom 320.
~20 phones
~Internal calls no problem SIP <-> SIP Fine
~server rebooted multiple times
I am remotely setup with a vpn to the main site. Using x-lite I called through the pbx out to the co and back into the pbx. The user on the polycom soundpoint 320 reported fuzz and volume issues as normal including echo. I was hearing none of these issues with the soft phone over a vpn! Whats up with this? Does the echo canceler on the tdm2400 only function with hard phones? Does the echo canceler not run with the soft phone due to latency or hops?
Anyone have experience with this?
I get this error message on every call:
Unable to request echo training on channel x
Does echo training not work with the echo canceler chip?
One aspect of this problem is the need to amplify the lines to hear the outside (ZAP) side of the conversation. I believe the fuzz is induced by the amplification. This would explain why the sound quality is an issue with the hard phones. They are trying to work with what they get. They amplify the volume and the fuzz and echo are much more noticable.
Having used fxotune to set the gains, how am I supposed to deal with this volume issue?
The polycom phone is maxec out on the volume and it is still not so loud that you can’t put the phone to your ear. At this volume, the fuzz is evident and echo is induced. The mic is picking up anything and everything causing silence supression of the ZAP side of the call. Any ideas?
Thanks!
I have run into this problem before at a couple of sites. What is the output of /proc/interrupts? Have you changed any of the gain settings in polycom sip.cfg or are they factory settings? Have you tried relocating the card in the server to another PCI slot? When I ran into this problem previously I noticed that the card actually picking up noise form the hard drives in the server. relocating it solved my problem. I hope this helps.
-Robert
CPU0
0: 1050744137 IO-APIC-edge timer
8: 3505 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 66 IO-APIC-edge i8042
14: 1604285 IO-APIC-edge ide0
177: 23702652 IO-APIC-level eth0
185: 725 IO-APIC-level ehci_hcd, uhci_hcd
193: 0 IO-APIC-level uhci_hcd
201: 1049463466 IO-APIC-level uhci_hcd, Wildcard TDM2400P
209: 0 IO-APIC-level uhci_hcd
217: 2038236 IO-APIC-level libata
NMI: 0
LOC: 1050821139
ERR: 0
MIS: 0
Polycom sip.cfg is mostly factory, but I have tried changing some of the gains to no real net affect. What do you suggest for gains?
I will try the card in a different slot.
Thanks!
PS… Volume on unit to unit calls (SIP to SIP) is just fine. It is when I make Zap calls that I have the most problems.
aj
Your Wildcard is sitting on a shared IRQ with uhci_hcd (usb??). I would try to move it to another slot or disable usb support from the BIOS. Hope this helps.
As for Polycom settings my gains are set to default and look like the following:
[color=red]<gains voice.gain.rx.analog.handset=“0”
voice.gain.rx.analog.headset=“0”
voice.gain.rx.analog.chassis=“0”
voice.gain.rx.analog.chassis.IP_300=“-6”
voice.gain.rx.analog.chassis.IP_4000=“3”
voice.gain.rx.analog.chassis.IP_430=“0”
voice.gain.rx.analog.chassis.IP_601=“6”
[/color]voice.gain.rx.analog.ringer=“0”
voice.gain.rx.analog.ringer.IP_300=“-6”
voice.gain.rx.analog.ringer.IP_4000=“3”
voice.gain.rx.analog.ringer.IP_430=“0”
voice.gain.rx.analog.ringer.IP_601=“6”
[color=red]voice.gain.rx.digital.handset=“-15”
voice.gain.rx.digital.headset=“-21”
voice.gain.rx.digital.chassis=“0”
voice.gain.rx.digital.chassis.IP_4000=“0”
voice.gain.rx.digital.chassis.IP_430=“0”
voice.gain.rx.digital.chassis.IP_601=“0”[/color]
voice.gain.rx.digital.ringer=“-21”
voice.gain.rx.digital.ringer.IP_4000=“-21”
voice.gain.rx.digital.ringer.IP_430=“-21”
voice.gain.rx.digital.ringer.IP_601=“-21”
voice.gain.rx.analog.handset.sidetone=“-14”
voice.gain.rx.analog.headset.sidetone=“-24”
[color=red]voice.gain.tx.analog.handset=“12”
voice.gain.tx.analog.headset=“3”
voice.gain.tx.analog.chassis=“3”
voice.gain.tx.analog.chassis.IP_300=“0”
voice.gain.tx.analog.chassis.IP_4000=“3”
voice.gain.tx.analog.chassis.IP_430=“42”
voice.gain.tx.analog.chassis.IP_601=“0”
voice.gain.tx.digital.handset=“0”
voice.gain.tx.digital.headset=“0”
voice.gain.tx.digital.chassis=“3”
voice.gain.tx.digital.chassis.IP_4000=“0”
voice.gain.tx.digital.chassis.IP_430=“-3”
voice.gain.tx.digital.chassis.IP_601=“6”
voice.gain.tx.analog.preamp.handset=“14”
voice.gain.tx.analog.preamp.headset=“23”
voice.gain.tx.analog.preamp.chassis=“32”
voice.gain.tx.analog.preamp.chassis.IP_430=“32”
voice.gain.tx.analog.preamp.chassis.IP_601=“32”/>[/color]
Good luck!
RC
Your issue sounds much like the issue I had only mine was with a SIP based chanel bank going to analog lines.
Any incoming audio would sound bad. Burried in hiss and “ripping” noises. Asterisk had a hard time picking the DTMF out of the mess, and the chanel bank would freak out and then take asterisk down a short time later. I was constantly mucking with the gain to try and inimize static and keep the DTMF recognition working.
This exact same system sat in my office for months being picked at every day and never pulled any of these tricks.
To make things even more confusing, any outgoing audio was clear as a bell. I mean spot on perfect. You had no idea of how bad it sounded going the other way.
One more data point, like in your case, an analog phne plugged into any of the lines sounded fine in both directions.
After a lot of thought, I am 99% sure that the incominig analog lines have a lot of high frequency noise on them, or your server may have too much electrical noise inside the case or on the power supply. Did you ever try the server in another location with different telco lines? That would tell you if it is the server or the lines.
One thing that has assisted me in prooving this point is I dug out an old DSL line filter, and out it in line with the most offensive of the phone lines (one of the 8 was much noiser then the rest) and while it did not 100% cure the problem, it went a long way as far as reducing it static and ripping noise on incoming audio.
My thought is that the liens have a lot of high frequency energy on them and this is well above the 4 Khz limit for sampeling at 8K, so the static and ripping noises you here are the low frequency aliases of the high frequency energy. The audio equlvelent of watching car tires start to spin backwards as a car speeds up in the movies.
The current solution is to can the chanle banks and go IP out of that office to an IP based provider. The dmark now terminates in a shared closet in another set of offices, and the copper between the two ends is a mistery. My first thought was to move the dmark into our own space and if the problem still persisted, to hang it firmly at the local telco’s doorway. The local telco will not give me a quote on the job, it is all time and materials to them. This makes it hard for me to get my boss to sign onto. He hates the unknown, thus the all IP based solution. After kicking the tires on this for a month or so now, this looks like it will be a money saver as well.
Good luck!
–Matthew
Thanks Matthew, those are some good suggestions. I had a recommendation from Digium that the echo canceler chip on the TDM2400 might be defective. I was to remove the chip and install HPEC (High Performance Echo Canceller) software from Digium. I followed the instructions and got it working. Just about the same results as with the echo can. Very low volume coming in, lots of hiss and noise.
Without a echo can or HPEC the volume was fine, though there was still the hiss and noise. It is actually better without the Echo can or the HPEC! There really wasn’t even any echo after running fxotune -i 5.
I have some filters, so I am going to put them inline and see what happens. The exact same server (Dell SC430) is used at another location where the phone lines were absolutely crappy. Qwest finally dug up a bad splice across the street yesterday and repaired the problem. They only did it because the T1 into the building kept going down.
The phone lines in this case got cut along with 2100 other pairs. The cut took out the 20 year old phone system. So I don’t have a baseline on line quality before and after the cut. I might try moving the server to another location just to see.
I didn’t move the TDM2400 to a different slot, however, I did move some wires around inside the case that might have been transmitting interference.
I will also disable USB.
I moved the tdm2400 to the other pci slot, removed the usb irq, installed DSL filters on all of the lines; reinstalled the echo canceler card, ran fxotune -i ;restarted zaptel and got these results
[root@localhost zaptel]# cat /etc/fxotune.conf
1=5,255,252,0,2,254,0,255,255
2=7,255,251,251,2,255,255,1,255
3=9,0,251,252,2,255,0,0,0
4=5,252,250,1,1,254,0,255,0
5=5,252,250,1,1,254,0,255,0
6=5,252,250,0,0,254,0,255,0
7=5,252,250,1,1,254,0,255,0
8=0,0,0,0,0,0,0,0,0
[root@localhost zaptel]# ./fxotune -d -b 1
Dumping module /dev/zap/1
echo ratio = 0.1348 (626.3 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 2
Dumping module /dev/zap/2
echo ratio = 0.1183 (549.6 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 3
Dumping module /dev/zap/3
echo ratio = 0.1473 (684.1 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 4
Dumping module /dev/zap/4
echo ratio = 0.1353 (628.4 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 5
Dumping module /dev/zap/5
echo ratio = 0.1381 (641.4 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 6
Dumping module /dev/zap/6
echo ratio = 0.1486 (690.2 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 7
Dumping module /dev/zap/7
echo ratio = 0.1403 (651.6 / 4645.1)
Done!
whah whah whah ejh ejh (sound from pac man when the ghost gets pac man)
I checked the settings again. Ran ./fxotune -vvv -i 91319731XXXX -l 8. The results were the same after restarting Zaptel as before. However, next I ran ./fxotune -s and then restarted zaptel. Amazing difference as seen below.
[root@localhost zaptel]# ./fxotune -vvv -s
fxotune: successfully set echo coeffecients on FXO modules
[root@localhost zaptel]# ./fxotune -d -b 1
Dumping module /dev/zap/1
echo ratio = 0.0119 (55.4 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 2
Dumping module /dev/zap/2
echo ratio = 0.0311 (144.3 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 3
Dumping module /dev/zap/3
echo ratio = 0.0113 (52.7 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 4
Dumping module /dev/zap/4
echo ratio = 0.0090 (41.9 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 5
Dumping module /dev/zap/5
echo ratio = 0.0100 (46.6 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 6
Dumping module /dev/zap/6
echo ratio = 0.0120 (55.7 / 4645.1)
Done!
[root@localhost zaptel]# ./fxotune -d -b 7
Dumping module /dev/zap/7
echo ratio = 0.0180 (83.5 / 4645.1)
Done!
So for clarification, putting in DSL filters improved sound volume when using the Echo Canceler chip. This also significantly improved echo cancelation results as seen above. ./fxotune -s was required after ./fxotune -vvv -i 91319731XXXX -l 8 for the changes to come into affect.
The lines are still scratchy, but at a more normal level. Now I need to get the Telco out to look at the lines with me.