I’ve just installed asterisk on ubuntu server 7.10, and I compiled zaptel-1.4.10, asterisk-1.4.18.1, and libpri-1.4.3.
Everything went fine and modprobe ztdummy returns no problems, however when I run zttest I get negative 799.xxxx% and -800.xxx%
In asterisk, running “zap show status” displays ZTDUMMY/1 .
the MOH and IVR prompts are extremely choppy because of this, so I unloaded zaptel/ztdummy and set internal_timing=yes. This seems to have corrected 99% of the choppyness, but I do get the occassional stutter/jitter sound even when calling from an ATA on the same subnet as asterisk, latency below 1ms. Conference seems to be unaffected.
Should I forget about timing and look elsewhere for the cause of IVR sound breakup? or is that still my problem?
Since im running a new(ish) kernel and my system is ancient (Pentium 2, 333MHZ with some old IBM motherboard) would it be correct to assume whatever the new timing source is that zaptel ztdummy is using is not even close to accurate on my system?
I had a similar problem with an old Gateway (566MHz Celeron) box (I was getting -200% from zttest). On boot, Linux was disabling ACPI because the BIOS was too old but an acpi=force turned it on and fixed the rttest results (99%) as well as correcting my choppy voicemenu sound. I also set lapic but don’t believe this had any affect.
So are you running ACPI or APM? If APM then maybe give ACPI a try.
Cheers,
John McCarthy.
P.S.
This is an AsteriskNOW 1.0.2.1 SIP-only configuration using an ekiga SIP softphone.
I know a lot of people have issues with hwclock not being able to be read…
you get an error about /dev/rtc
I had to change ACPI to S1 in my BIOS, it’s a newer motherboard, it also had a bios timer thing for WMPlayer in Vista, disabled that too…
hwclock now works properly even without the --directisa option.
also make sure your timing source is /dev/rtc
genrtc does not work at all I don’t think, and the newer dev-rtc may not either…