[Asterisk-Users] Cannot get two TE410Ps to operate correctly in the same machine

[Peter Svensson]

On Sat, 27 Nov 2004, Rich Adamson wrote:

> > There is a 
> > buffer but the buffering can only handle jitter, not compensate for 
> > frequency difference. 
> 
> No, you're assuming a one-byte (or very small) buffer, and that's not 
> what's going on in asterisk.

You misunderstand me. I know that the buffers are larger. However, even if 
they are 1 second deep they will eventually empty / overrun. There is no 
way about this except to either allow data to be invented/dropped or to 
keep the source and sink in perfect sync.

> > If the spans on the two cards are kept in sync the 
> > data going from one card to the other will be consumed exactly as fast as 
> > it is written. 
> 
> Maybe in utopia, but that's certainly not asterisk. You've been around
> this list long enough to have read the many discussions relative to
> interrupt latency, and some of those latencies are directly assoicated
> with human recognized echo, etc. Those issues imply delays through the
> system upwards of a bunch of milliseconds, with hugh variations depending
> upon what other devices grab the pci bus. So, you couldn't keep the data
> flow to be "exactly in sync" if you tried real hard.

You do not have to have the pci bus in sync though, as long as the two 
cards are in sync. I do understand the operation of buffers on the two 
cards and in Asterisk. The data does not have to flow *instantaneously* 
(as is done in traditional telecom systems) but it does have to flow at a 
constant rate meassured over the time comparable to the buffer depth.

The interrupt latency is a red herring. Extremely precise interrupt timing 
is _not_ needed to communicate the clocking from one board to another.

> You can't implement phase lock loops, etc, to control the bus issues
> either without modifying the motherboard and/or digium cards. No one
> is going to go there.

No, it would probably not be that hard. You can infer the needed frequency 
changes on the slaved board bu observing the level of the buffer. If it 
drains too fast data is being consumed too fast and vice versa.

> > This will keep the buffers from overfilling / draining.
> > 
> > The fact that a buffer is involved is no magic bullet that solves 
> > everything. 
> 
> That's true, but it _is_ what you've got to work with in *, like it
> or not. Its not been an issue for anyone that has implemented multiple
> digium cards, so I guess it boils down to don't fix it if it ain't
> broken.

It is only a problem when you want to get data connections across the bus. 
For modem communications you will get a failed crc and possibly a 
retraining each time data is invented / dropped. For a fax the problems 
may be worse.

For Unrestricted Digital connection I wonder what happens. I guess they
are not allowed across boards? (They do work very nice within a board
though, this is very nice).

I agree very much that this is a non-issue for voice. 

Peter