On 08/19/2012 11:45 AM, Lee Howard wrote:
On 08/17/2012 04:58 AM, Steve Underwood wrote:
On 08/17/2012 06:08 AM, Eric Wieling wrote:
Has anyone experimented with increasing the DAHDI chunk size in
improve fax reliability? If so, did it help, hurt, or not make any
difference?
I haven't found issues related to the DAHDI chunk size. The main
thing which used to hurt FAXing with Asterisk before Digium launched
their own FAX software was the timing within Asterisk, which they
refused to fix at that time (although independent patches were
available). With the launch of FFA they changed chan_dahdi so on a
FAX call the buffering should change to make the flow of transmitted
audio a lot more elastic. People just tolerate some hiccups in voice
calls, but hate latency. Modem signals must be rigidly timed, but a
bit more latency is OK. This change fixed the main issue affecting
all the FAX solutions around. If that switch in the buffering mode is
not happening on your system for some reason it can badly affect the
reliability of FAXes.
I'm uncertain of exactly to which changes you're referring. Your
comments seem to fall in-line with the notion behind the DAHDI
"buffers" feature for the channel as well as the DAHDI fax-detection
"faxbuffers" feature, but I'm seeing no noticeable improvement, AND
I'm uncertain how to implement the CHANNEL(buffers) feature due to:
-- Executing [4628160@fax-outbound:1] Set("IAX2/ttyIAX99-584",
"CHANNEL(buffers)="12,half"") in new stack
[Aug 18 20:12:40] WARNING[6381]: func_channel.c:530
func_channel_write_real: Unknown or unavailable item requested: 'buffers'
-- Executing [4628160@fax-outbound:2] Goto("IAX2/ttyIAX99-584",
"outbound,4628160,1") in new stack
-- Goto (outbound,4628160,1)
-- Executing [4628160@outbound:1] Dial("IAX2/ttyIAX99-584",
"DAHDI/g0/4628160") in new stack
On some installations there are occasional instances in most outbound
calls where Asterisk creates what otherwise would be considered jitter
on the DAHDI channel. Generally these do not cause much real-world
trouble, but I'm a stickler for perfect audio quality on all-digital
calls. I've seen this on Asterisk versions 1.4, 1.6, and 1.8. On
other installations there never is any such trouble noticeable.
Would you mind being a bit more specific on the Asterisk changes to
which you refer and how they should be implemented in the configuration?
I was referring to the DADHI buffer control, which is (or was the last
time I looked) tied in with the DADHI channel's fax detection scheme. It
was never that big a problem with iaxmodem for some reason. The timing
of things passing through Asterisk was always handled more smoothly than
the timing of things originating from within Asterisk.
For smooth audio flow you need to have plenty of audio buffered up in
the DADHI transmit queue. Sometimes DADHI doesn't get serviced for quite
a long time, and the queue needs enough stored audio to prevent
underflows. The same issue can cause buffer overflows on the audio
receive side, and additional buffers certainly help there, but underflow
on the transmit side was always the dominant problem.
Steve
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
