Date: Thu, 23 Aug 2001 11:11:26 -0400 From: The Anarcat <anarcat@anarcat.dyndns.org> To: Stuart Barkley <stuartb@4gh.net> Cc: Juha.Nurmela@quicknet.inet.fi, freebsd-multimedia@freebsd.org Subject: Re: precisions of pcm driver problems and update of rec program Message-ID: <20010823111126.B1566@shall.anarcat.dyndns.org> In-Reply-To: <20010823021827.B12745-100000@precipice.4gh.net> References: <Pine.BSF.4.10.10108230820340.23830-100000@lpr-325.cable.inet.fi> <20010823021827.B12745-100000@precipice.4gh.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 23 Aug 2001, Stuart Barkley wrote: > On Thu, 23 Aug 2001 Juha.Nurmela@quicknet.inet.fi wrote: >=20 > > Have you guys ever wished the sound-device would provide a > > VU-level indicator for the generic mixers ? Without interfering > > with a recorder process. I don't think this is "completely" possible. That is, you can't have a VU indicator for the mic channel if you're already recording on the line channel, for example. This is just the way soundcard works, if i'm not mistaken... > I hadn't thought about it this way, but this is one reason I've been > playing around with my own record program. It does make some sense to > include if you can handle that last condition. But the thing is it's not really something that the kernel *must* do, but a thing that it *could* do.=20 As such, I would like better to have support for multiple opens (because it would have to be implemented internally for the meter anyways) altogether and run the meter as a userland process than have thousands of specific gizmos in the kernel, sorry, no offense here.. > > It could sample randomly over 10...50% of samples when rates are > > high, or whatever, if the extra load is bothersome (and obviously > > only be effective when the /dev/pcm/vumeter is open). I wonder how > > this kind of additional device would fit in pcm driver. >=20 > I haven't really been into the driver code, but it could be a > performance issue, particularly if the driver needed to do any byte > order conversions or other manipulations on the data. Yeah, and from what you've sent, it also involves logarithmic computations and max comparaisons to be really useful. This too much computation to put in the kernel, IMHO. This should be userland. As you mentionned earlier, we have to read each sample to find the max in order to detect clipping, which is mandatory, for a meter, IMHO. > Perhaps this function does better belong in the record program. Yes. Actually, it belongs to a filter program that I will shortly write. :) > I've looked at dap and it has a record level meter. It has no scale > information so I've found it pretty useless for real use. Indeed. Also, dap is huge and cannot mix multiple channels. I haven't used dap for a very long while now.. I also think there was some memory issues with it (as with mxv: loading the whole sample into memory and trusting the virtual memory manager, simply mad). > > There's a audio spectrum visualizer too, which I once wrote for > > Xlib and fftw. Don't know if it's any good, but has been a handy > > tool for miscellaneous twoway radio adjustments. > > http://personal.inet.fi/koti/juha.nurmela/ascope5.c > > (scope it is not, false name, yes) Note: I needed to add -I/usr/X11R6/include in the compile comand line. :) Also note that I tested it using: ../rec - | ./ascope5 -A /dev/stdin Another fun thing to do is: esdmon | ./ascope5 -A /dev/stdin to check esd output. :) > YES! This looks to be pretty close to what I'm thinking about > (including an X interface which I was dreading to need to deal with). Yes, it is really nice. It just tells me right now that my left channel has 2 big noises at around 3940 and 4060. Hmm.. I must investigate that. Must be the cable. :) Anyways, great tool! Just a few comments, if you don't mind.. Take it as a wishlist. :) - fast/slow button are unitiutive: took me a while to understand what it was for. should be a function of the window size or something... Anyways, since the window can't scroll, what use is it to have detail on only a part of the spectrum? I'm not sure I understand what they do. - the little white numbers are annoying :) there should be scales on the sides instead. - the vertical green lines should be wider to accelerate display - both channels should be display at once, either as a single or double graph Also, I would be looking for a similar tool having just one display: the *overall* VU/dB/level meter. No need for the frequency, just the peaks, to adjust incoming mixer levels. How hard would that be to implement in ascope? I also have a CPU problem here: CPU states: 16.6% user, 0.0% nice, 6.2% system, 2.7% interrupt, 74.5% id= le Mem: 34M Active, 6372K Inact, 15M Wired, 4780K Cache, 14M Buf, 404K Free Swap: 250M Total, 37M Used, 213M Free, 14% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 40252 anarcat 2 0 2388K 1080K select 0:35 10.50% 10.50% ascope5 343 root 2 0 17544K 8104K select 24:43 8.94% 8.94% XFree86 it *is* taking a bit too much cpu. :) If the lines would be thicker, I think performance would improve. You guys are great, I think we're actually getting somewhere here. :) A. --pvezYHf7grwyp3Bc 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 iEYEARECAAYFAjuFHR0ACgkQttcWHAnWiGd2iwCfTYVSYT2WFjnI37BYzRA0IjXV o2UAoJb69BISqQ7jx7f51LxMv1khw5o0 =+cSI -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- 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?20010823111126.B1566>