Date: Tue, 21 Aug 2001 17:08:08 -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: <20010821170808.F28830@shall.anarcat.dyndns.org> In-Reply-To: <20010821143852.W7029-100000@precipice.4gh.net> References: <20010821114703.B5114@shall.anarcat.dyndns.org> <20010821143852.W7029-100000@precipice.4gh.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Qz2CZ664xQdCRdPu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 21 Aug 2001, Stuart Barkley wrote: > [not copied to mailing list. feel free to reply there.] >=20 > On Tue, 21 Aug 2001, The Anarcat wrote: >=20 > > I have made a few more updates to my rec program, since my last > > post (aug 15). >=20 > You might want to include the URL next time. I had saved your > previous messages so was able to find your files anyway.=20 Darn.. Always the same mistakes.. :) The url is: http://anarcat.dyndns.org/ftp/pub/FreeBSD/local/src/rec/ > However, > there seemed to be some permission problems with several of the files. Fixed. > > The program now fully conforms (I think) to the new OSS API as > > described in the PDF. Display has been improved, a play mode has > > been implemented, and a few other things has been changed (see the > > ChangeLog). >=20 > You seem to going down the same path I'm currently doing but are maybe > a little further along it. I also have crude record and play raw file > utilities. Interesting. > 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. :) > 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.=20 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. > At the same time, I want to read back the signal from a > mic and display an FFT or similar output. =20 I do not understand. What is a FFT? Are you talking about real-time effects here? > > 3) dsp vs dspW issues > > > > it seems that the data is "filled" when in RAW, sample: > > > > 00000000: 43fe 8efe 37fe 9dfe 3ffe 90fe 3efe 8dfe C...7...?...>... > > 00000010: 3dfe 97fe 44fe 93fe 31fe 95fe 48fe 9efe =3D...D...1...H... > > 00000020: 38fe 95fe 3dfe 94fe 36fe 9bfe 37fe 8afe 8...=3D...6...7... > > > > This does not happen in the new version, when using -d /dev/dsp > > and -w, but still happens with -d dspW and -w, which is odd. >=20 > I'm getting good record data with all 16 bits (with my program). =20 Using dsp or dspW? Using dsp seems to be fine here. > > 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.=20 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). That said, let's see: > I haven't tried yet, but I assumed you could open /dev/dspW for R/W > and set each direction independently.=20 I don't think OSS supports assymetric audio formats. And in -stable, you cannot open dsp devices twice. > Simple separate processes (my > program) didn't seem to be able to read and write at the same time. For the above reason, I guess. > 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. > > 2) -c n where n > 2 will likely not work. >=20 > # channels? I guess that would be limited by the hardware.=20 Of course. My sound blaster does not allows c > 2 or < 1. But given proper hardware, I don't think rec would DTRT with c > 2. > I've > actually though about writing an output file from my proposed tool > which would include 4 channels: the 2 output channels which were > generated and the 2 input channels which were captured. =20 Interesting. But, as I said, why not capture the data and *then* process it to create a seperate file or duplicate channels? And doesn't sox just do this? Record using rec and process using sox or your software. :) > Later offline tools could then do more detailed analysis of the data. >=20 > > 6) AIFF mode has not been tested with this year's changes >=20 > I have only been playing around with raw files so far. It might be > good to support/allow other formats, but I'm still very unclear of > which formats have what advantages.=20 I initially chose AIFF because the sample stream didn't need a lot of correction or processing. And the header was of almost static size, allowing interruptible recordings to edit the header in cleanups. It was working fine, I don't know if it still works, but I think it would. However, keeping a RAW-only output keeps the program simple. That is why I am not developping AIFF anymore and that I ifdef'd it in the source. > It would be nice to have sample > rate, bits, number of channels, etc inside the file. =20 That's why formats such as AIFF exist. If you look at aiff.c, you have the writeCOMMChunk() functi which writes the header, including sample rate, size (which can be modified if interrupted, using seek; see updateSizeFields), and format... I have no documentation on the WAVE format, so I did not write an output "plugin" for it. But I think WAVE features about the same thing as AIFF. > 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"? > > Please test at will and comment. I think I'm almost there! :) >=20 > Okay. Yay! > > Oh, and note that the AIFF mode is in the way of being deprecated. > > I have no time test and adapt to the massive latest changes. I > > request help here. I might work on this once the "raw" version is > > stable. >=20 > As above. AIFF might be good, but "raw" is good enough to get > started. Yay. Screw AIFF. :) A. --Qz2CZ664xQdCRdPu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Pour information voir http://www.gnupg.org iEYEARECAAYFAjuCzbcACgkQttcWHAnWiGdk+QCfTwn8s+0aigB0WPTpArZ9t44i mLgAnRKzfVUfSZjDyn1XBw/UXSoYOm+a =mYjq -----END PGP SIGNATURE----- --Qz2CZ664xQdCRdPu-- 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?20010821170808.F28830>