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 _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users