[Asterisk-Users] Alternatives to SpanDSP??

[Andrew Kohlsmith]

On April 27, 2005 09:04 am, Rich Adamson wrote:
> I would sort of disagree with the spiking thingie (now). If you modify
> the zttest app to provide timing output in terms of seconds and
> microseconds, you don't see the spiking impacting those measurements.
> Rather, you see 8,192 bytes arriving in something greater then 1.000
> seconds on a very consistent basis.

Do you have a copy of this patch?  I'd like to work on this problem with you 
(in my ample spare time, ha!).

> The design of the card (and asterisk) is 100% oriented around receiving
> 8,192 bytes from the card every 1.0000 seconds exactly. Any significant
> variation from 1.000 seconds will result in a missed frame (1024 bytes)
> sooner or later.

*nod*

> What I've not been able to figure out is "why" the delay. I'm 95% sure
> it has more to do with asterisk code (including drivers) then it does
> with other system interrupt handlers, interrupt latency, etc. Those
> _other_ things certainly can impact it, but there is definitely
> something within asterisk that is directly related to the TDM card
> and its drivers. (Its almost consistent enough to look closer at the
> clocking on the TDM itself. That assumes a clock on the TDM card is
> responsible for raising the interrupt to the O/S via the pci bus.)

Well the clock on the TDM400P is the same as what is used in the T100P, X100P 
(or is it X101P?) and TE110P.  It's just a cheap crystal oscillator within 
the TJ320 so at least in theory the same problem should exist with those 
cards if it were an oscillator issue.

Even cheap oscillators are more accurate than this though.  :-)  I'm curious 
though if the CPU spiking in the wctdm driver has something to do with it 
(causing the time to stretch), especially since this isn't seen on the other 
cards, only within that driver, and it's only that card that seems to have 
it.

(I'll reply to your original post about the zttest stuff in -dev and we can 
continue this there.)

-A.