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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] Indexing the Read Pointer in /dev/dsp
From: Martin McCormick (martin_AT_dc.cis.okstate.edu)
Date: Tue May 04 2004 - 23:40:37 EEST


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue May 04 2004 - 23:36:58 EEST