From owner-freebsd-multimedia Wed Aug 22 12: 4:17 2001 Delivered-To: freebsd-multimedia@freebsd.org Received: from precipice.4gh.net (precipice.4gh.net [63.73.57.6]) by hub.freebsd.org (Postfix) with ESMTP id B5CFE37B43C for ; Wed, 22 Aug 2001 12:03:05 -0700 (PDT) (envelope-from stuartb@4gh.net) Received: from localhost (stuartb@localhost) by precipice.4gh.net (8.9.3/8.9.3) with ESMTP id OAA12622; Wed, 22 Aug 2001 14:57:39 -0400 (EDT) (envelope-from stuartb@4gh.net) Date: Wed, 22 Aug 2001 14:57:38 -0400 (EDT) From: Stuart Barkley To: The Anarcat Cc: Subject: Re: precisions of pcm driver problems and update of rec program In-Reply-To: <20010821170808.F28830@shall.anarcat.dyndns.org> Message-ID: <20010822135453.W8939-100000@precipice.4gh.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 #include 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