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

Martin McCormick martin at dc.cis.okstate.edu
Tue May 4 16:40:37 EDT 2004


Malcolm Baldridge writes:
>Funny, I've written a simple program (derived from the Jack "simple_client")
>recent to do something similar.

	That sounds impressive.  Someone correct me if I am wrong, but
Jack requires X windows for just about everything.

	As a computer user who is blind, X is just not quite ready to
productively use yet.

	My program uses the raw /dev/dsp PCM audio device.  Without
any IOCTL directives, this device reads and writes a 8
thousand sample-per-second stream of 8-bit audio.

	It is great for communications audio and no good for anything
else.:-)

	My program idles by reading the samples and looking for any
that are a given value above or below 0X80 which is the value one gets
from the A/D converter under silence.

	If there is a swing through 0 to the other side of the cycle,
a flag gets set.  I make sure that several 0 crossings go by to avoid
transient trips and then I set the VOX delay timer which tells the
rest of the program to store samples in the output file.

	There is a buffer between the input and output so as to
preserve the wave form and not chop it off.

	I burn roughly 25 megs for each hour of captured audio.

	I don't see anything wrong with making a new file for each
recording, but I think there is a limit to the number of files one can
have in a directory.  That is the only pitfall I can see.

	There is one more bell to this program.  If the sample read is
0 or 1 at one extreme or 0Xfe or 0Xff at the other, I send the bell
character to warn that the audio is probably going in to clipping and
to reduce the input level.  The warning functions like a peak indicator.

>What it does (for now, I'm sure I'll be adding more to it) is:
>
>1) Monitor the command-line specified input port for a sound above the
>squelch level.
>
>2) Apply a configurable DC Bias adjustment [squelch comparison is performed
>after this]
>
>3) Keep track of the peak samples processed to pass a "scaling value" to
>normalise the sound data. [This is also post-DC Bias adjustment.]
>
>3a) I'm also looking at various dynamic compression [gain reduction] strategie



More information about the Linux-audio-user mailing list