asterisk users - Sep 2006 - asterisk, iaxmodem, hylafax quality problem

Hello,

My setup is PRI card, Asterisk, iaxmodem, hylafax or PRI card,
Asterisk, channel bank, fax machine. I'm using Fedora Core 4, iaxmodem
0.1.14, hylafax 4.3.0, asterisk 1.2.10.

Everything is fine when caller use ECM but when ECM isn't in use I
often got unusable incoming faxes (much often that it should be). But
when I switch back to fax machine that receive faxes perfectly (at
least no visible error).

Where should be the problem? Is there any solution for improving
quality? Any tuning in Asterisk or Hylafax? As I see some people use
slinear for iaxmodem and some user use alaw. Which is better?

What config should I post if that needed for ideas?

bye,
Zsolt

Are you use digium card?
digium pri card offen cause many problems, check zttest

Artifex Maximus wrote:
> Hello,
>
> Everything is fine when caller use ECM but when ECM isn't in use I
> often got unusable incoming faxes (much often that it should be). But
> when I switch back to fax machine that receive faxes perfectly (at
> least no visible error).
>
> Where should be the problem? Is there any solution for improving
This belongs on the HylaFAX mailing list.

Doug

-- 
 
Ben Franklin quote:

"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety."

Artifex Maximus wrote:
> Everything is fine when caller use ECM but when ECM isn't in use I
> often got unusable incoming faxes (much often that it should be). But
> when I switch back to fax machine that receive faxes perfectly (at
> least no visible error).

The fax machine itself uses ECM, undoubtedly.  If callers that have 
quality problems with IAXmodem+HylaFAX don't have problems with the fax 
machine, then that strongly indicates that something is wrong with your 
Asterisk setup... corrupting the audio.  Usually this is due to resource 
constriction of the Zap device, zttest scores less than 99.98% is 
indicative of that situation.
> Where should be the problem? Is there any solution for improving
> quality? Any tuning in Asterisk or Hylafax? As I see some people use
> slinear for iaxmodem and some user use alaw. Which is better? 

There is no functional difference between using uLaw, alaw, or 
slinear... except that using slinear reduces the need for conversion... 
and thus possibly lessens CPU usage very slightly.

Lee.

Hello,

# cat /proc/interrupts
           CPU0
  0: 2087872259    IO-APIC-edge  timer
  7:          0    IO-APIC-edge  parport0
  8:          1    IO-APIC-edge  rtc
  9:          1   IO-APIC-level  acpi
 14:   18440124    IO-APIC-edge  ide0
 15:    4456445    IO-APIC-edge  libata
169:    4878102   IO-APIC-level  eth0
177: 2086847525   IO-APIC-level  wctdm24xxp
185: 2086810653   IO-APIC-level  wct4xxp
NMI:          0
LOC: 2087921792
ERR:          0
MIS:          0

zttest is often on 99.975586% with final result:
--- Results after 67 passes ---
Best: 99.987793 -- Worst: 99.951172 -- Average: 99.973764

Where should I find good web pages for tuning? I had found this and using now:
setpci -v -s 04:06.0 latency_timer=ff
setpci -v -s 04:08.0 latency_timer=ff

As I remember it's give higher priority for Digium cards. The machine
is an IBM eServer x206 with P4 2.66 GHz processor.

bye,
Zsolt

On 9/23/06, Ma Zhiyong <zhiyong.m@gmail.com>
wrote:
> zttest don't disturb your other active calls. when you have 10-20
> calls maybe got a better score.
> also cat /proc/interrupt and 'lspci -vb' to find any IRQ interrupt
on
> your system.
>
> 2006/9/22, Artifex Maximus <artifexor@gmail.com>:
> > Hello,
> >
> > On 9/21/06, Lee Howard <faxguy@howardsilvan.com> wrote:
> > > Artifex Maximus wrote:
> > >
> > > > Everything is fine when caller use ECM but when ECM
isn't in use I
> > > > often got unusable incoming faxes (much often that it should
be). But
> > > > when I switch back to fax machine that receive faxes
perfectly (at
> > > > least no visible error).
> > > The fax machine itself uses ECM, undoubtedly.
> > That's unfortunately not the case. The remote doesn't asks for
ECM so
> > that's disabled or missing on that machine. In this situation fax
> > machine is produce better output and I don't know why. Might a
better
> > DSP algo?
> >
> > > If callers that have
> > > quality problems with IAXmodem+HylaFAX don't have problems
with the fax
> > > machine, then that strongly indicates that something is wrong
with your
> > > Asterisk setup... corrupting the audio.  Usually this is due to
resource
> > > constriction of the Zap device, zttest scores less than 99.98% is
> > > indicative of that situation.
> > I don't find any info that zttest is destructive or not on an
active
> > system. I mean that currently active calls are disturbed or not while
> > zttest running. I can't stop system now. I look into zttest source
and
> > find that zttest is using /dev/zap/pseudo but I don't know this
> > 'pseudo' channel is related to any 'real' channel or
not.
> >
> > > > Where should be the problem? Is there any solution for
improving
> > > > quality? Any tuning in Asterisk or Hylafax? As I see some
people use
> > > > slinear for iaxmodem and some user use alaw. Which is
better?
> > > There is no functional difference between using uLaw, alaw, or
> > > slinear... except that using slinear reduces the need for
conversion...
> > > and thus possibly lessens CPU usage very slightly.
> > I see. I leave it on slinear.
> >
> > bye,
> > Zsolt

Artifex Maximus wrote:
> zttest is often on 99.975586% with final result:
> --- Results after 67 passes ---
> Best: 99.987793 -- Worst: 99.951172 -- Average: 99.973764

This is unacceptable for faxing, and it is evidence of the underlying 
problem also causing your faxes to come through with poor quality.
>  0: 2087872259    IO-APIC-edge  timer
>  7:          0    IO-APIC-edge  parport0
>  8:          1    IO-APIC-edge  rtc
>  9:          1   IO-APIC-level  acpi
> 14:   18440124    IO-APIC-edge  ide0
> 15:    4456445    IO-APIC-edge  libata
> 169:    4878102   IO-APIC-level  eth0
> 177: 2086847525   IO-APIC-level  wctdm24xxp
> 185: 2086810653   IO-APIC-level  wct4xxp 

Notice the priorities here... and that your Zaptel cards come *last*, 
after eth0, after IDE.  Each of those Zap cards are going to generate an 
interrupt once every millisecond when in use.  You can hopefully imagine 
how IDE or eth0 activity would interfere, since they have a higher 
priority than the Zap cards.

Lee.

Hello,

Sorry for returning such an old topic but it looks like I found a
solution. I am using FC5 on an IBM x206 with TDM2400P and TE405P.

Using this general guide:
http://www-128.ibm.com/developerworks/library/l-hw2.html
and this hint
http://pastebin.ca/32678

I had put pastebin.ca stuff into /etc/rc.d/rc.local and my problems
are gone. The zttest gives lower values but more stable:

Opened pseudo zap interface, measuring accuracy...
99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586%
99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586%
99.975586% 99.975586%
99.975586% 99.975586% 99.975586%
--- Results after 18 passes ---
Best: 99.975586 -- Worst: 99.975586 -- Average: 99.975586

bye,
Zsolt

On 9/24/06, Lee Howard <faxguy@howardsilvan.com>
wrote:
> Artifex Maximus wrote:
>
> > zttest is often on 99.975586% with final result:
> > --- Results after 67 passes ---
> > Best: 99.987793 -- Worst: 99.951172 -- Average: 99.973764
>
>
> This is unacceptable for faxing, and it is evidence of the underlying
> problem also causing your faxes to come through with poor quality.
>
> >  0: 2087872259    IO-APIC-edge  timer
> >  7:          0    IO-APIC-edge  parport0
> >  8:          1    IO-APIC-edge  rtc
> >  9:          1   IO-APIC-level  acpi
> > 14:   18440124    IO-APIC-edge  ide0
> > 15:    4456445    IO-APIC-edge  libata
> > 169:    4878102   IO-APIC-level  eth0
> > 177: 2086847525   IO-APIC-level  wctdm24xxp
> > 185: 2086810653   IO-APIC-level  wct4xxp
>
>
> Notice the priorities here... and that your Zaptel cards come *last*,
> after eth0, after IDE.  Each of those Zap cards are going to generate an
> interrupt once every millisecond when in use.  You can hopefully imagine
> how IDE or eth0 activity would interfere, since they have a higher
> priority than the Zap cards.
>
> Lee.