Date: Wed, 22 Aug 2001 16:33:43 -0400 From: The Anarcat <anarcat@anarcat.dyndns.org> To: Stuart Barkley <stuartb@4gh.net> Cc: freebsd-multimedia@freebsd.org Subject: Re: precisions of pcm driver problems and update of rec program Message-ID: <20010822163343.B1561@shall.anarcat.dyndns.org> In-Reply-To: <20010822135453.W8939-100000@precipice.4gh.net> References: <20010821170808.F28830@shall.anarcat.dyndns.org> <20010822135453.W8939-100000@precipice.4gh.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 22 Aug 2001, Stuart Barkley wrote: > 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. Really interesting. I modified rec code to display time and byte counts updates only once a second, so I could be possible to keep a "max" variable somewhere (or dB) and send it to an external display function. I must setup such a function soon enough to be able to display time progress in both raw and AIFF mode. > To convert these numbers to dB use something like: >=20 > #include <limits.h> > #include <math.h> >=20 > float dB =3D log10((double)SHRT_MAX / max) * 10.0; Nice. Got it. > 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. The problem with the max thing is that you must examine each single sample taken and compare it to a max, replacing the max in worst case, before writing it to file. This is time consuming. Also, this is all well if we're recording 8 bit unsigned, however, 16 bit data is little endian signed. That's crap. We then have to cast 2 elements of an array into a signed tmp and convert if correctly to unsigned to make a similar analysis. That sucks. On the top of my head: #ifdef LITTLE_ENDIAN 1: unsigned char buf[2]; /* array containing one sample */ 2: u_int16_t val =3D (int16_t) buf + INT_MIN; 3: if (val > max) max =3D val; 4: float dB =3D log10((double)UINT_MAX / max) * 10.0; #endif Line 2 and 3 would get executed about err.. 44100 times per second? :) Not good. I think I'll do it though... Even if it's in a seperate program. rec can already pipe it's output out to stdout so it would be better off this way... > Yes. Simple is good, and my thoughts do keep going down the trap > towards complexity. Then I think we agree here. The time calculations are already enough garbage in rec's code. Let's make other stuff simple filters that read samples, not soundcards. :) > > > 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? >=20 > An FFT (Fast Fourier Transform) display lets you see the frequency > spectrum of the data. I'll probably use the fftw package. Interesting. This is not the same as the waveform displays we see in editors such as WaveLab, right? More an EQ display or what? > > Are you talking about real-time effects here? >=20 > 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. [...] I understand better now. I basically want to use a soundcard as a benchmark tester or tuning device for external devices. That's really interesting. I believe that with the advent of full-duplex support (and consequently multiple opens of audio devices) for pcm, this will be achievable using simple programs such as rec and play, and auxiliary filters. > > > > 4) it seems we can independantly specify dsp and dspW (ie dsp can r= ecord > > > > 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. >=20 > 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. But this wasn't the behavior of the pcm driver before. :) I had problems with that in the earlier days of rec, that's why I was confused. All is clear now. :) > > 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). >=20 > 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. We'll need some input from Cameron here, but I think that the newpcm driver will indeed allow multiple opens of the dsp device, using DEVFS cloning techniques and such hacks. And I think Cameron mentionned something about full-duplex being supported on -stable if you build the right devices. I haven't been able to make this work though... > > 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. >=20 > 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(). Hmm... ok.. I will wait for input from Cameron on the status of the multiple open issues. I think we shouldn't complicate the code if multiple opens are eventually allowed. > A simple program would be best and my next step will be to pipe stdin > to audio output and audio input to stdout. It might be possible to modify rec to operate in both "play" and "record" mode at the same time, reading data from stdin and writing to stdout. It does seem to be an ackward behavior though. > > > 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"? >=20 > 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. Interesting. If you have one of these jewels around, give me a call, and I'll try to make rec work in > 16 bit! :) A. --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuEFyYACgkQttcWHAnWiGccuACfRWVNvUTUTZS9Xcd7kH98L9IC ZXAAoIZeGYAnaZu7b04N0dggHlyu6z7l =wMyU -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- 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?20010822163343.B1561>