[Asterisk-Users] Re: Problems with TDM400P card

[Mike Mueller]

On Wed, May 04, 2005 at 03:58:52PM -0600, Rich Adamson wrote:

First off, I want to say that I'm getting involved because this is
interesting and I want to contribute.  I am just getting started with Asterisk
so smack me if I say something stupid.

<snip> 
> I think we all understand the 8000 per second. That's not an issue at all
> at the pcm level. However, the TDM card sends 1024 byte frames, not 1000
> byte frames. 

Frame? It's an octet stream of one octet per 0.000125 sec.  It doesn't
matter if they are delivered in chunks of 50, 100, 1000, or 1024. Just
got to use the corresponding time expectation: n * 0.000125.

I understand in this thread from now on, "frame" means a group of 8192 
sample octets that should arrive every 1.024000 seconds.

> The original zttest.c triggers on data=>8000, and that 
> translates into 8192 bytes each 1.024 second (etc).

zttest.c looks fine to me (in absence of Linux scheduling delays).

It loops 8 times, and count is 8192 > 8000 so the time report is made.

First the seconds element of elapsed time is used to calculate how many
chunks of 8000 octets should have arrived.  Next the microsecond element
is used to calculate how many additional octets should have arrived 
(1,000,000 / 125 = 8000).

Consider the following:

	sec		usec
------------------------------------
start    5              998,000
now      7               22,000 (1.024 sec later when 
                                 8192 octets arrive)

The calculation yields:

1. (7 - 5) * 8000 = 16,000
2. 16,000 + ((22,000 - 998,000)/125) = 8,192 octets should have arrived

This calculation, however, assumes no unwanted delays from the Linux scheduler.

zttest.c is a user space program.  There is no
guaranteed latency between the 8th read and the refresh of the "now"
timestamp.  A long delay could jack up the expected number of octets and
make the percentage calculation go below 100%.

The general Linux scheduling algorithm can insert some long delays where
and when you don't want them.  All of the numbers reported in this thread are
in the 99.9xxxx% range aren't they?  Given how this code is being
run, I think that's fair indication that the TDM samples are coming at
the expected rate.  If you need better accuracy, then you'll need to put
some tools into the driver code.

> 
> So, 8000 bytes in one second is the same thing as 8192 bytes in 1.024000
> seconds. 

Yep. 1.000000 sec that is, and that is the problem in a nutshell.
> 
> We're still looking for the root cause as to why the TDM card is missing
> frames "in a large percentage" of implementations, negatively impacting
> things like spandsp. 

Frames in this context means the chunks of 8192 octets collected in zttest.
What I understood was that frames weren't missing. Instead some of
these reports on 8192 samples were less than 100% which suggested
samples were not arriving in a timely fashion. I contend that zttest is
inherently incapable of making such a determination accurately, primarily
because the calculation depends on low latency which cannot be assumed
in a user space program running under the general Linux scheduling
alorithm. (You could try SCHED_FIFO policy to improve things; can give
code chunk and advice on how to not lock up the node if needed).

> According to Steve Underwood, spandsp _did_ work
> with the TDM card some time back and its his general feeling that 
> something has changed that has negatively impacted it.

When I called Digium they were forthcoming about recent problems and improvements
when asked about defects being discussed on the user list. They said there 
have been recent firmware improvements with echo-can and some
other stuff (the nature of which I can't remember).  Could changes or
flaws with echo-can have affected spandsp?

I am new to Asterisk, but so far, having looked at this thread (which is
quite long and full of lot's of hard work), the zttest code, the Digium web site,
and the spandsp website, and having talked to Digium sales/support about
the TDM, I think the issue belongs the spandsp community.  They may be
able to point out an improvement to the TDM product that Digium may or
may not implement.  Or they may need to adapt to an improvement on new TDM
cards. It does not appear that Digium has promised support to
the spandsp add-on function to Asterisk. I also didn't see where the spandsp
project was committed to staying up to date with each new revision of
TDM card - that's what the community is for.

In summary, it doesn't appear that spandsp not working and zttest output
is sufficient to cast doubt on the TDM cards.  More comparison between
working and non-working spandsp faxing apps might give more reliable
clues about where the problem lies. 

Also, what other applications like spandsp are not working with TDM
cards?

Thanks for letting a noob jump in.  This is some fun sh*t!
-- 
Mike