On Tue, May 03, 2005 at 09:28:23PM +0000, Tony Mountifield wrote: > I wrote: > > In article <[EMAIL PROTECTED]>, > > Rich Adamson <[EMAIL PROTECTED]> wrote: > > > > > > 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. > <snip> > [EMAIL PROTECTED] 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
Whew! At least the kernel module is using the len :). > 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 > [EMAIL PROTECTED] 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. Why? Computers are base-2 oriented and POTS digital telephony is based on adapting to human hearing perception and a massive installed base of analog equipment. Working with base-2 numbers in computer programs is common and often efficient. 1/8000 = 0.000125 sec/sample octet (8 * 1024)samples * 0.000125 sec/sample = 1.024 sec Looks good to me. > > But zaptel.c is Deep Magic, and I'd be interested in comments from those > who are famliar with it in detail. Bah. Just your average 6459 line kernel module ;). I've seen bigger. Here are some guides: http://www.oreilly.com/catalog/linuxdrive2/ http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html -- 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