[Asterisk-Users] Re: Problems with TDM400P card

[Rich Adamson]

> > >  - a modified zttest.c run on both systems to show the delays in reading
> > >    8192 bytes from the TDM card as 23,850 microseconds lateness on
> > >    the old mobo, and 24,000 microsecond lateness on the new system. No
> > >    significant change resulting from the differences in mobo, pci
> > >    structure, interrupt structure, cpu speed, quantity of ram, kernel
> > >    differences (v2.4 vs v2.6), etc.
> > 
> > See my response to your zttest-mod.c posting. I think it is 8000 bytes
> > that are due every second, not 8192. That would make the timing on your
> > new system pretty accurate if 8192 bytes are arriving in 1,024,000us.
> 
> Tony is correct.  You should expect 8000 octets/sec from a digital
> sampler on a POTS line interface.
> 
> http://lists.digium.com/pipermail/asterisk-users/2005-May/105148.html
> 
> Reference:
> http://www.ncta.com/industry_overview/cableGlossary.cfm?indOverviewID=41
> 
> Sample Rate - In analog to digital signal processing, the sample rate is
> the interval at which samples of an analog signal are taken. The sample
> rate for digital telephony, for example, is 8000 per second. 
> 
> http://www.freesoft.org/CIE/Topics/127.htm
> 
> G.711 is the international standard for encoding telephone audio on an
> 64 kbps channel. It is a pulse code modulation (PCM) scheme operating at
> a 8 kHz sample rate, with 8 bits per sample. According to the Nyquist
> theorem, which states that a signal must be sampled at twice its highest
> frequency component, G.711 can encode frequencies between 0 and 4 kHz.
> Telcos can select between two different varients of G.711: A-law and
> mu-law. A-law is the standard for international circuits.

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. The original zttest.c triggers on data=>8000, and that 
translates into 8192 bytes each 1.024 second (etc).

So, 8000 bytes in one second is the same thing as 8192 bytes in 1.024000
seconds. (Note: I screwed up in my original post by saying the objective
was 8,192 bytes in 1.0000 seconds.)

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