Playback stutter
Submitted by CallTheGuru on Tue, 01/22/2008 - 2:25pm.
Hi. I'm having an issue with audio quality and not sure where it's coming from.
No outbound trunks yet, waiting for SIP trunk to come in.
Have just 2 extensions now, one is FW 2.2 (seems buggy and slow) other is 1.6.7.
They can call each other fine and I can leave messages.
But if I dial a wrong extension or outside line I get this:
Th - e n-u-m-b-e-r y - ou h-av-e di-a-l-ed c-a-nn-o-t b-e c-o-nn-e-c-t-ed at th-i-s.....
You get the point All play back on the system does this weird stutter sound, including retrieving voice mail messages. I'm assuming messages are recorded properly. If I call one extension to the other and pickup, voice quality is as it should be.
My system is:
Intel mainboard DQ35JO, Intel P4D 3.2, 512MB DDR2 667, Onboard RAID 1, mirrored 80GB HD, onboard Intel NIC, Dual-core enabled in BIOS
Trixbox 2.4 ISO without any updates except to the FreePBX modules(core, framework, dashboard)
Any ideas? I'm adding more memory tonight to see if that makes a difference.
I'm suspecting that the RAID array is my issue, but I don't know why...poor drivers in CentOS 5.1?
Any help anyone can offer is greatly appreciated!
Thanks,
R
Fixed IT!
Wed, 01/23/2008 - 12:46am
Jitter is fixed.
I had configured the Intel mainboard for onboard RAID 1. I assumed that the TB 2.4 ISO would detect it (the onboard configured 'fake-raid') and do a corresponding install...seemed to install fine and the HD specs in control panel seemed correct.
Jitter, Jitter, Go Away, but it would not. Added RAM, - n/g, but it's good to have 1GB.
Install the tbm-raid admin tool (Thanx Trixbox!) from Packages and found out that raidstatus was not configured. Arrrrgh...
Boot ISO and pressed F2, found the sataraid option. (Why didn't I do this before??)
Boot to BIOS, disable Intel RAID, set drive type to AHCI.
Boot ISO, use sataraid option, finish the install, reconfig, update, transfer .cfg files....
Tried playing back voicemail and canned messages - NO JITTER!!!
Hope this helps someone out there.
R
Jitter came back
Thu, 01/24/2008 - 12:48pm
Sometime yesterday, the jitter returned when playing back VM or canned Asterisk messages. All I had done was add a remaining 10 extensions (out of 12) using FreePBX. Applied changes, configured and booted a new phone and BOOM - jitter!!!
I knew it wasn't the hard drive, so I figured network. Reconfigured everything - N/G
This morning, I used a PCI NIC instead of the onboard, reconfigured, and the jitter went away.
But then, I removed the PCI NIC, used the onboard, reconfigured, and the jitter was still gone.
Could someone PLEASE help me figure out what is going on here?
Thank You!
R
What are you using to talk to the phones?
Thu, 01/24/2008 - 5:34pm
I had jitter/cutouts on recordings from other phone systems (ie Sam in the office calls an outside number that has a recording saying "I've moved to this number ...... " but only every second second (???) gets through, or "I-mo-d-to-th-num-r-8-4-5-6")
The inside voicemail did a similar thing to.
I played around with the codecs being used and it seems to have helped
Michael
Codecs
Thu, 01/24/2008 - 5:51pm
Thank You for answering Michael.
I checked the first 4 phones and they're all configured to use G711.mu-law. Also, each of them now reads about 7ms jitter, but a little while ago they were in the 23ms - 40ms range.
Did I answer your question? If I have to change codecs, where would I do that from? SIP.cfg probably? How would I specify it?
Sorry to ask so many questions... I'm just having a hard time with this, being my first trix 2.4 install and I've NEVER had issues like this before.
Jitter is not back yet. If it comes back again, I'm going to check packet stats on the phones and the network...see what I can find there.
R
Jitter came again, but it's gone
Thu, 01/24/2008 - 7:10pm
I added a Wildcat TDM400 to try some outgoing POTS calls. After booting up, all of the 4 registered phones were jittering.
So I KNOW it's not hard drives, and it's not REALLY a NIC issue. So, I figured an IRQ shifted somewhere, but this darned 'advanced' Intel board has absolutlely no facility for setting IRQs (obviously). It's only got one white PCI slot and 3 black PCI-X 1e slots (the relaly short PCI Xpress slots).
Booted to the BIOS and started poking around. Saw the PCI Latency timer was set to 32. What's this? It's the number of cycles that a PCI device has to finish it's job or to give control over to the next PCI device. I figured if it's a network issue, let's bump that latency up. So I set it to 128 and booted.
Changed nothing else and there's no jitter now.
Any thoughts?
Does anyone at Fonality have input on this issue?
Inconsistently fixed
Sat, 02/02/2008 - 7:35pm
2-1-08 - moved the system into production environment - 2 phones - boot it up - JITTER! Reboot, gone (wtf ???)
2-2-08 - came in to add remaining 10 phones. Browse to FreePBX and see the errors about php in some modules. Search forums and see that Asterisk is NOT running, even though it is (?). While connecting a KVM switch to get access to the actual console, and not through PuTTy, I booted the server. JITTER! Reboot, JITTER. Disc patch cable, reboot, JITTER! Now I'm scared. Reboot edit BIOS, turn on HPET, N/T. BIOS, turn off HPET, increase PCI Latency Timer to 192 from 128 (see previous posts), reboot - No JITTER!
Kerry? Anyone at Fonality? I'm really stumped by this, I'm certain is a hardware timing issue between the hard drives and some other component(s). Could anyone please give input?
Thanks very much!
Same Here
Sun, 02/03/2008 - 8:51am
Hi CallTheGuru,
same problem here with two Intel motherboards. One with hardware raid enabled , the second with sataraid working and hw raid set do AHCI.
All incoming and outgoing calls are fine with GXP-2000 and Snom 360.
Every sound coming from tb like VM and Echo test, speaking clock etc... gives Jitter.
Perhaps something referring to this error?
[Feb 3 16:03:07] WARNING[22399] rtp.c: Unable to set TOS to 184
Tried also disabling Core MultiPlexing and clock=pit with no success
Anyone?
Mabybe a timing problem?
Mon, 02/04/2008 - 11:26am
I think I have timing problems with & without TDM400P
TB is not running in virtual machine, is a brand new standalone Intel Core 2 with RAID and 2 GB of ram
Let have a look to zttest
[trixbox1.localdomain ~]# zttest
Opened pseudo zap interface, measuring accuracy...
22.648239% 5.879688% 6.098437% 12.402058% 19.441891% 7.479000%
--- Results after 6 passes ---
Best: 22.648 -- Worst: 5.880 -- Average: 12.324886, Difference: 187.675114
Very very bad with both pc
this is the result of Interrupts handling
[trixbox1.localdomain ~]# cat /proc/interrupts
CPU0
0: 45109228 XT-PIC timer
1: 2 XT-PIC i8042
2: 0 XT-PIC cascade
8: 1 XT-PIC rtc
9: 0 XT-PIC uhci_hcd:usb3, ehci_hcd:usb7
10: 895095 XT-PIC uhci_hcd:usb1, uhci_hcd:usb4, uhci_hcd:usb6, ehci_hcd:usb8, libata
11: 45261658 XT-PIC uhci_hcd:usb2, uhci_hcd:usb5, wctdm
12: 4 XT-PIC i8042
105: 1237840 PCI-MSI ahci
113: 59838 PCI-MSI eth0
NMI: 0
LOC: 45161772
ERR: 0
MIS: 0
Anyone?
Timing
Mon, 02/04/2008 - 1:05pm
ccataldo:
Thanks for picking up on this thread.
Have you tried adjusting the PCI Latentcy timer in your BIOS? I'm curious what your result would be if you changed the default (32 cycles) to 128 cycles.
My zttest results CURRENTLY (no stutter) are as follows:
99.486519% 99.968170% 99.487495% 99.773727% 99.772560% 99.583199.....
Results after 14 passes
Best: 99.968 Worst: 99.487 -- Average 99.705698, Difference: 100.294301
R
CallTheGuru
Mon, 02/04/2008 - 4:39pm
Fresh installation, again... No luck with PCI Latency to 128, still hearing Jitter... and worst results...
[trixbox1.localdomain ~]# zttest
Opened pseudo zap interface, measuring accuracy...
-9.449434% -7.903314% -9.044933% -8.391905%
--- Results after 4 passes ---
Best: 0.000 -- Worst: -9.449 -- Average: -8.697397, Difference: 208.697397
wctdm is sharing IRQ 11 but I don't know if and how I can change the TDM interrupt. Anyway, also without TDP400P I have the same problem.
[trixbox1.localdomain ~]# cat /proc/interrupts
CPU0
0: 305637 XT-PIC timer
1: 2 XT-PIC i8042
2: 0 XT-PIC cascade
8: 1 XT-PIC rtc
9: 0 XT-PIC uhci_hcd:usb3, ehci_hcd:usb7
10: 5779 XT-PIC uhci_hcd:usb1, uhci_hcd:usb6, libata, HDA Intel
11: 286145 XT-PIC uhci_hcd:usb2, uhci_hcd:usb4, uhci_hcd:usb5, ehci_hcd:usb8, wctdm
12: 4 XT-PIC i8042
105: 15612 PCI-MSI ahci
113: 21928 PCI-MSI eth0
NMI: 0
LOC: 305010
ERR: 4
MIS: 0
Playback stutter
Mon, 02/04/2008 - 11:47pm
It's always a good idea to use the forum search function to see if something already discussed might apply to your problem. I believe that doing so in this case might have found you an answer before now.
The "XT-PIC" strings in your "/proc/interrupts" is the clue that the old style interrupt handling is being used. I think your solution may lie in the parameters given to the linux kernel when it starts. These can be changed in the "/etc/grub.conf" file. Make sure the line that starts with "kernel" does not contain the parameter "NOAPIC" and try changing the "acpi=off" parameter to "acpi=on". Then, reboot the system.
Keep in mind that a number of people have found that even though this is the "correct" setting for modern systems, it causes their Trixbox 2.4 systems to crash regularly. So, you might fix your problem, or you may trade it for something worse. This is why "on" is not the default setting now. I suspect that this is either a bug in the RHEL5/CentOS5 kernel or the result of people trying to use hardware (motherboard in this case) that is too new and not properly supported yet in Enterprise class Linux. Keep in mind that Linux in general usually lags behind a bit in support for new hardware and the Enterprise class Linux lags even more.
Beyond this possible fix, your only other options may be to use a not so recently designed motherboard, or wait for RHEL5/CentOS5 to be fixed/updated to work with your current hardware while using the "correct" kernel parameters.
Interrupts
Tue, 02/05/2008 - 12:00am
Joe:
Thanks very much for your response! If the stutter returns on my system I'll look at my interrupts and try what you've suggested (Not that I understand it fully, but I'm trying)
Is there a place one could go to understand more about kernel startup options?
Thank You,
R
Solved?
Tue, 02/05/2008 - 1:46am
I don't know exactly how to change my actual /etc/grub.conf that is
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/mapper/isw_fggegiggi_RAIDp2
# initrd /initrd-version.img
#boot=/dev/mapper/isw_fggegiggi_RAID
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title trixbox (2.6.18-53.1.4.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-53.1.4.el5 ro root=LABEL=/ acpi=off
initrd /initrd-2.6.18-53.1.4.el5.img
If I remove acpi=off, system locks at boot
I also decided to use the HW Raid not using sataraid because I had a lot of errors.
Solved?
Tue, 02/05/2008 - 10:28am
ccataldo
I couldn't use the HW raid b/c CentOS5 install seemed to be seeing past it and not doing RAID properly. sataraid options has worked well for me and I've tested it by disconnecting a hard drive and system kept functioning. Then I rebooted and rebuilt the array, took about 30 minutes.
Have you reinstalled again? How's the sytsem(s) doing now?
R
Same problem - any fixes in 2 months?
Wed, 05/07/2008 - 10:27pm
Change to using acpi=on helped me
Wed, 05/14/2008 - 4:40pm
We just installed a new server for a SIP only system. Boy was I surprized that the old Pentium 3 recorded sounds were better than the new dual core machine. I did not build the system, and I don't know how to look in /proc to find the board type. However, it made all of the difference in the world when I change grub.conf (/boot/grub/grub.conf) so that the line the kernel directive for acpi was now "on" insteand of "off".
Hopefully, the system will be stable. In any case, I have all the phones dual registered -- one to the old box and the other to the new box -- in case the new box fails.
Jack
Member Since:
2007-07-06