[linux-audio-user] Indexing the Read Pointer in /dev/dsp

[Martin McCormick]

	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