I have the beginnings of a program I have written that listens to the digital stream from /dev/dsp and records sound to a file when there is any sound. Communications types call this a VOX or Voice Operated relay with X being the abbreviation for relay. I want to also make a log of the time each recording started which is relatively easy to do especially if one uses the extensive time and date functions in UNIX. I think I can even store the stamps in the binary file with the audio. Retrieving those data in a meaningful manner, however, seems to be a problem. I want the playback program to display the time of the start of each recording as it begins to play. The /dev/dsp device is buffered so what really happens when you play a file is that the file pointer runs ahead of the actual byte being pushed through the sound card at any given time. The operating system blocks any more data being stuffed in to /dev/dsp, but the byte being pushed in may be 64 Kbytes ahead of what is playing right now. That's the problem. If I wrote a program to display the time a recording started, you would see that stamp some variable amount of time from instantly to maybe 8 seconds ahead of when the corresponding sound came out the speakers. I have been experimenting with methods of editing binary files and one has the same problem there in that when you reach the place you wanted to cut the virtual tape, the data which are flowing in to /dev/dsp are about 8 seconds past that point and it is hard to tell exactly where to edit. Is there any function that returns some offset or index value as to how much buffer is left? The trick to putting time stamps in with the audio should be to not ever allow a value of 0 to be stored from the A/D converter. When a new recording starts, store a NULL or 0 in the file followed by the 32-bit time and date value that UNIX systems store. Audio can follow after that. When playing back the file, look for the 0 and then use the next 4 bytes to recover the time and date. This would be a piece of cake if not for that variable buffer. The buffer is essential, however, for proper sound. I think that this buffer is actually the DMA channel at work so an indicator that it had run out or would soon run out would also be useful for those who want to synchronize sound with other activities. I have been playing with the VOX program for a couple of years and it works pretty well for recording radio transmissions but two transmissions could be anywhere from a quarter of a second apart to days apart. The program neatly cuts out the silence, but one has no idea when each recording actually started. In amateur radio, such information is useful when unusual skip or propagation conditions are present or in cases of malicious interference or malfunctions when one is trying to document when a particular event happened. For those of you used to recording high fidelity, the 8 seconds I refer to is with mono audio at 8,000 samples per second. Other sample rates and sample widths will certainly de pleat the buffer much faster. Martin McCormick WB5AGZ Stillwater, OK OSU Information Technology Division Network Operations Group
