[Asterisk-Users] Alternatives to SpanDSP??

[Rich Adamson]

Cross posting on purpose to transition the thread to -dev

The issue in this thread is the frame transfer rate for the TDM analog
card almost always exceeds the 1.000 seconds expected by the design.
The frame transfer rate seldem impacts voice (the missed frames aren't
noticed), but seriously impact code such as spandsp.

> From: Andrew Kohlsmith <akohlsmith-asterisk at benshaw.com>

> 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!).

No I don't. I just inserted printf's in the 80+ line app to inspect
the actual timing values (as opposed to viewing that mostly meaningless
percentage number).

> > 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.

That crystal oscillator is supposedly a standalone component that
drives whatever other chips (on the card) the designer wants to use
if for. Presumably, it is driving the 3050 (I didn't check). But,
through some mechanism, the 3050 is serially sending pcm data bytes
to the TJ320, and it appears _it_ buffers up that data and raises
the pci interrupt to the O/S. So, any component associated with that
process is including in my definition of "clocking" the interrupts
(not just the crystal).
 
> 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.

If one includes a couple of printf's to watch the seconds and microseconds
used in the zttest calculation, then execute 'zttest -v', the reported
times will consistently be something like 1.021234 seconds. Even though
vmstat shows the spiking, it does not show up in the time reported for
the zttest to receive 8,192 bytes of data. That would suggest the spiking
isn't the root cause for the TDM card's missed frames.

Since the vmstat spiking occurs roughly every ten seconds, one would
expect it to have an impact on at least some of the zttest output.
But, I've not seen that happen as yet.

Opinion: the TDM analog card is subject to a number of system level
issues, but underlying those issues seems to be an asterisk-code problem
(including drivers) that does not support receiving the expected 8,192
bytes from the TDM card in 1.0000 seconds. (According to Steve Underwood, 
that was not a problem about six to nine months ago, but it is now.)

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

I'll modify the zttest.c app and post the mod's on the -dev list, and
maybe we can narrow down the root cause for the TDM issues. 

Direct eamil for those that want is fine (radamson at routers.com).

I'll be out of the office for the remainder of today, but will continue
with this later today or tomorrow morning.

Rich