> Hi
>
> I wonder if anyone has any sugestions
>
>
> I have had a TDM400 for a couple of years, and I have always had problems
> with noise on the line, so tonight I have been doing some research and have
> found that if I load the CPU dahdi_test has almost perfect results and no
> noise
>
> dahdi_test
> Opened pseudo dahdi interface, measuring accuracy...
> 99.997% 99.999% 99.998% 99.997% 99.999% 99.998% 99.998% 99.998%
> 99.998% 99.998% 99.998% 99.997% 99.998% 99.997% 99.998% 99.998%
> 99.998% 99.998% 99.998% 99.997% 99.999% 99.998% 99.998% 99.997%
> 99.998%
> --- Results after 25 passes ---
> Best: 99.999 -- Worst: 99.997 -- Average: 99.997895, Difference: 100.002028
>
>
>
> but when the CPU is not loaded there is white noise low volume and the
> results of dahdi_test
>
> dahdi_test
> Opened pseudo dahdi interface, measuring accuracy...
> 99.992% 99.988% 99.951% 99.991% 99.992% 99.992% 99.992% 99.992%
> 99.991% 99.991% 99.992% 99.991% 99.991% 99.952% 99.992% 99.992%
> 99.992% 99.992% 99.951% 99.992% 99.992% 99.992% 99.992% 99.950%
> 99.991% 99.991% 99.991% 99.992% 99.992% 99.951% 99.992% 99.992%
> 99.992% 99.991% 99.952% 99.992% 99.992% 99.991% 99.992% 99.951%
> 99.991%
> --- Results after 41 passes ---
> Best: 99.992 -- Worst: 99.950 -- Average: 99.984461, Difference: 100.001168
>
>
> Could you explain how I can improve the call quality without running the
> CPU at 99% al the time?
>
> running the latest Dahdi 2.4.0 Echo Canceller: OSLEC and asterisk
1.6.2.13
I suspect that you might be seeing some effect of the CPU
going into, and out of an IDLE state... possibly due to the
use of the HLT instruction in the kernel's idle loop, or
possibly due to the ACPI BIOS (or the operating system
"cpufreq" support code) changing the CPU clock rate or
voltage.
These sorts of changes in processor state might have several
sorts of effects on the TDM400P card and the audio it is
processing:
- Changes in processor state (e.g. core voltage or clock speed)
can cause a brief interrupting in processing... the CPU
instruction processing must sometimes be halted in order to
allow the clock PLL to re-lock at a different rate and for
the core voltage to stabilize. This might possibly be adding
enough latency to interrupt service time to affect the card
(e.g. losing some audio samples), or skewing the timing enough
that OSLEC's echo cancelling algorithms exhibit different
behavior.
- Changes in the amount of power being drawn by the CPU, when
it goes from flat-out processing to idle, can be quite
substantial in modern CPUs. Some of today's multi-core CPUs
dissipate on the order of 100 watts during full-speed processing
but drop down far below that when idle. The amount of current
being drawn by the processor will cause changes in the voltage
on the motherboard's +12 and +5 supply lines, and these voltage
changes are likely to reach the TDM400P. If the TDM400P doesn't
have good on-board voltage regulation and noise filtering (and
I suspect that it might not), then some of the voltage noise on
the supply rails could leak into the audio. Similar problems
exist with many PC on-the-motherboard audio interfaces.
As to how to fix it? Well, you're going to have to experiment.
The first thing I'd suggest trying, would be to see if you can
disable any sort of ACPI- or kernel-based "power saving" adjustment
of the CPU's clock speed and core voltage. This might involve
disabling SpeedStep (or the equivalent) in the BIOS, or switching
Linux from using the "ondemand" power governor to a single-speed
one (either "performance" or "powersave" or
"usermode").
Possibly, running Asterisk at a real-time priority might reduce
the issue, if it's timing-related.
If it's simply a matter of noise on the power rails, you may not
be able to get rid of it at all easily... might have to change
motherboards, power supplies, or switch to an external phone
interface device which is inherently immune to electrical noise
within the PC chassis.