Date: Wed, 22 Aug 2001 14:57:38 -0400 (EDT) From: Stuart Barkley <stuartb@4gh.net> To: The Anarcat <anarcat@anarcat.dyndns.org> Cc: <freebsd-multimedia@freebsd.org> Subject: Re: precisions of pcm driver problems and update of rec program Message-ID: <20010822135453.W8939-100000@precipice.4gh.net> In-Reply-To: <20010821170808.F28830@shall.anarcat.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Aug 2001, The Anarcat wrote:
> On Tue, 21 Aug 2001, Stuart Barkley wrote:
>
> > I have some code to display a running dB indication so the record
> > level can be monitored. I'll look at your code when I can and see
> > what integration possibilities might be.
>
> Nice!!! This was something I was looking for!!! I do think it
> would be possible to include it. The data passes through the
> program using an unsigned char array, so you could just interpret
> that, if you have an handy function around. :)
The main thing is to find minimum and maximum values over an interval
of interest. You will be clipping if you are hitting the maximum or
minimum values. My initial code just displayed these values over each
1 second interval so I could visually see what was happening.
To convert these numbers to dB use something like:
#include <limits.h>
#include <math.h>
float dB = log10((double)SHRT_MAX / max) * 10.0;
This can let you see the range of your data (how many dB below the
maximum signal). For recording you do not want to reach 0dB or you
will be clipping. You might also be distorting when you are close to
0 dB but that depends upon lots of other factors in the audio source
stream. Since peaks can be much higher than the average, its the
peaks you need to control.
> > My short term goal is to be able to do signal generation (tones,
> > variable pitch and volume, pink noise, etc) and feed into an external
> > sound system.
>
> Hmm... I think rec should do just one thing: interface the sound
> driver to get PCM data out of it. It should do as less processing
> possible to be as reliable as possible. Small is beautiful. :)
>
> I want mostly to avoid the "traps" sox is into because it is a
> general sound processing system, and not a recording tool.
Yes. Simple is good, and my thoughts do keep going down the trap
towards complexity.
> > At the same time, I want to read back the signal from a
> > mic and display an FFT or similar output.
>
> I do not understand. What is a FFT?
An FFT (Fast Fourier Transform) display lets you see the frequency
spectrum of the data. I'll probably use the fftw package.
> Are you talking about real-time effects here?
I am looking at doing a certain type of real time processing. The
specific short term application I'm talking about is to be used to
tune an external sound system to match the location.
By sending a known signal into the sound system and examining the
result actually captured by a microphone you can adjust the sound
system for best reproduction of the signal. In this case the computer
is just a tuning tool and isn't used once the system is calibrated.
You can send a 440 Hz signal, measure the level seen by a microphone
and use this as a baseline. You then send a 880 Hz signal and using
an equalizer on the external system adjust things until this signal is
received at the same level. Repeat for other frequencies.
By using "pink" noise and an FFT display you can see all frequencies
at once and get a better visual feel for the behavior.
There are lots of other complications and I'm really just playing
around at this point in time. Complications include things like the
frequency response of the microphone, quality of the D/A and A/D
converters and probably lots of other things I'll learn about as the
process continues.
> > > 4) it seems we can independantly specify dsp and dspW (ie dsp can record
> > > 8 bit?), it's just that dspW scraps 16 bit output (!!)
>
> Let me rephrase this: it seems we can open dsp and dspW
> interchangeably without any difference except default sample
> format. In other words, using -d dsp or -d dspW doesn't make a
> difference.
Yes. That is what the OSS documentation says and that is what I'm
seeing. My current program sets format, sample rate and number of
channels. Both /dev/dsp and /dev/dspW behave identically.
> I am not talking about simultaneous opens of dsp devices or
> full-duplex operation. This should be operated by the driver (and
> is in -current, IIRC).
The OSS documentation indicates that only a single process can open
the dsp. This means that if both read and write are required a single
program will need to do both functions. I'm not following -current
and haven't noticed this has a change.
> > select() isn't too hard to use, but program structure does need to
> > take it into account. Threads might be another possibility. In
> > either case it does start becoming a more complicated program than a
> > simple test bed utility.
>
> As mentionned earlier, I wish rec to be as simple as possible.
> Avoid threading/select if possible. And it is. :) The driver
> should take care of multiple opens of dsp.
From the OSS documentation it looks like R/W must be done by a single
program. I'm going to look at incorporating this into my code
probably using select().
A simple program would be best and my next step will be to pipe stdin
to audio output and audio input to stdout.
> > I suspect that if I really get very serious I'll be wanting 20-24 bit
> > A/D (and maybe D/A) conversion.
>
> Is that an external module or a "soundcard"?
Yes. Actually I haven't really looked at this closely yet. I think
there are a number of options including both special soundcards and
external USB devices. By keeping the audio signals outside of the
computer you card reduce the interference from the electric noise
inside the chassis.
Stuart
--
I've never been lost; I was once bewildered for three days, but never lost!
-- Daniel Boone
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010822135453.W8939-100000>