[Asterisk-Users] Re: TDM users: modified zttest.c for testing

[Rich Adamson]

> > > It would be very interesting to see everyone's results in running
> > > this, and even more interesting to report the results with the OS
> > > distro in use, mobo in use (if known), etc. If anyone actually
> > > get's a result that is very close to 1.000 seconds, I'd really
> > > like to know more about those systems. (email off list is fine
> > > if you want.)
> > 
> > --- Results after 20 passes ---
> > Best: 1.024003 -- Worst: 1.023981 -- Average: 1.023993
> > 
> > This looks very close to 1024ms instead of 1000ms. That got me thinking:
> > 
> > I believe your premise is wrong. The sample rate of telephony audio
> > is 8kHz. With 8-bit samples (uLaw or aLaw), that means 8000 bytes
> > should be supplied in 1 second, not 8192.
> > 
> > At a rate of 8000 bytes/sec, 8192 bytes will arrive in 1.024 seconds.
> 
> I've done a few more tests and think I may have uncovered a problem in
> the pseudo-driver. Whether it's relevant to Rich's problem I don't know,
> but it might have something to do with MeetMe drift on SIP channels.
> 
> I modified Rich's program as follows:
> 
> a) Changed "char buf[8192];" to "char buf[SIZE];" (SIZE is 8000).
> 
> b) Changed the objective line to:
> 
> printf("Objective: to read %d bytes from TDM card in 1.000000 seconds.\n", sizeof(buf));
> 
> On running it again I was surprised to find it STILL showing times for
> 8192 bytes instead of 8000.
> 
> I added the following line just after the read() in the main loop:
> 
> printf("\nread(fd, buf, %d) returns %d", sizeof(buf), res);
> 
> That showed me that read(fd,buf,8000) was returning 1024 bytes.
> 
> Aha, so by the time count >= SIZE, it had read 8 blocks totalling 8192.
> 
> I changed the read to res=read(fd,buf,sizeof(buf)-count) so it would stop
> at 8000 bytes, and got the following results:
> 
> [root at softins zaptel]# ./zttest-mod -v
> Objective: to read 8000 bytes from TDM card in 1.000000 seconds.
> Opened pseudo zap interface, measuring accuracy...
> 
> read(fd, buf, 8000) returns 1024
> read(fd, buf, 6976) returns 1024
> read(fd, buf, 5952) returns 1024
> read(fd, buf, 4928) returns 1024
> read(fd, buf, 3904) returns 1024
> read(fd, buf, 2880) returns 1024
> read(fd, buf, 1856) returns 1024
> read(fd, buf, 832) returns 832
> 8000 bytes in 1.023988 seconds
> read(fd, buf, 8000) returns 1024
> read(fd, buf, 6976) returns 1024
> read(fd, buf, 5952) returns 1024
> read(fd, buf, 4928) returns 1024
> read(fd, buf, 3904) returns 1024
> read(fd, buf, 2880) returns 1024
> read(fd, buf, 1856) returns 1024
> read(fd, buf, 832) returns 832
> 8000 bytes in 1.023998 seconds
> --- Results after 2 passes ---
> Best: 1.023998 -- Worst: 1.023988 -- Average: 1.023993
> [root at softins zaptel]# 
> 
> So it looks like the pseudo driver is always handling 1024 byte chunks,
> and even if you ask it for fewer bytes, it takes 1024 bytes' worth of
> time.
> 
> I think it should really be handling 1000-byte chunks in 125ms rather
> than 1024-byte chunks in 128ms, if it is supposed to be emulating
> telephony channels.
> 
> But zaptel.c is Deep Magic, and I'd be interested in comments from those
> who are famliar with it in detail.

Tony, that is exactly the same path I was looking at when I modified
the zttest.c code. However, it appears I got caught making assumptions
relative to 1024 * 8 = 8192 bytes in 1.000 sec when it now appears the
correct number really is 1.024 sec. 

I have to be out of the office today, but will dig into the above
tonight to see what can be discovered in zaptel. (I'm not a very
proficient coder though.)