[asterisk-dev] Zaptel drivers

[Matthew Fredrickson]

On Aug 8, 2006, at 2:33 PM, Tim Johnson - Eclipse Electronic Systems 
wrote:

> I hope I'm in the correct place to be asking this question.  I'm 
> having a hard time locating resources for assistance with the Zaptel 
> modules and how to extract data from the character devices.  In other 
> words, not using Asterisk.  I'm basically just using an E1 link to 
> send basic PCM audio over in a particular channel (channel 1 in my 
> case).  On the machine with the Digium card (TE205P) I'm simply trying 
> to get the PCM audio out and into a sound card.
> As a first step however, I'd just like to be able to pull the data out 
> and just store it in a file and be able to correlate it to the data 
> that was sent.
> I've been fumbling around quite a bit, and trying to use some examples 
> from ztmonitor and zttool.  Right now I'm just opening /dev/zap/1 and 
> doing reads and ioctl calls to for status.  Status reads look good.  
> It looks like, but its hard to tell, when an alarm is either set, or 
> cleared on a span, due to remote activity like a card reset, my 
> ability to communicate with the character device becomes broken.  Any 
> read from it or ioctl call, just returns -1at this point, until I 
> re-open the character device.  Then I seem to be able to communicate 
> with the device again.  I don't know why this happens or what the 
> correct way to handle it is.

Whenever a zap channels receives an event, you have to clear the event 
on the channels before you can read audio again.  You might look at the 
ZT_GETEVENT ioctl for more information about it.  You shouldn't have to 
reopen the file descriptor to access the audio again.

> To start with, I was simply cat'ing /dev/zap/1 >> test.bin and viewing 
> the file in a hexeditor.  When no data is being sent, the pattern out 
> is constant, when the data begins getting transferred into the TE205P 
> over the E1 link, I see this data pattern
     ^^^^^^^^^^^^^^^^^^^^

This is to be expected, you set the channels as a clear channel.  When 
the channels are not in audio mode, they transmit 0xff continuously, 
otherwise they transmit silence (according to the default codec of the 
channel, alaw or ulaw).

> become erratic.  So I know that at some level at least, the modules 
> are doing their job.  Also, if send data in on channel 1, and I cat 
> /dev/zap/2, I see no change in the data pattern between not 
> transmitting and transmitting.  So I know that the channels are 
> getting split up and routed correctly.  But if I look at the data out 
> on /dev/zap/1, and try to correlate it to the data a transmitted from 
> the other machine, nothing matches.
>
> Am I heading the complete wrong direction here in trying to use 
> /dev/zap/1?  If using /dev/zap/1 is correct, is there someway I need 
> to be setting up so that I actually tell when I have real data coming 
> and not an idle, seemingly random but constant pattern out (might be a 
> repeated '0x3fff' or '0xffff', or '0x7e7e')?
> I've pasted my /etc/zaptel.conf file in as well.  Maybe I'm doing 
> something wrong there, that someone can point out.
>
> If this is completely the wrong place and you know of a better place, 
> please let me know.  I can't really find anything zaptel specific.
> Thanks,

You might look into the patgen.c and pattest.c applications in zaptel 
trunk.  They are good examples of doing transmission and receiving of 
audio on zap channels that definitely work.

Matthew Fredrickson