From owner-freebsd-multimedia Sun Sep 19 20:10:18 1999 Delivered-To: freebsd-multimedia@freebsd.org Received: from pluto.ipass.net (pluto.ipass.net [198.79.53.5]) by hub.freebsd.org (Postfix) with ESMTP id D5332151A6 for ; Sun, 19 Sep 1999 20:10:11 -0700 (PDT) (envelope-from rhh@ipass.net) Received: from stealth.ipass.net. (ppp-1-101.dialup.rdu.ipass.net [209.170.132.101]) by pluto.ipass.net (8.9.3/8.9.3) with ESMTP id XAA05543; Sun, 19 Sep 1999 23:10:05 -0400 (EDT) Received: (from rhh@localhost) by stealth.ipass.net. (8.9.3/8.8.8) id XAA02242; Sun, 19 Sep 1999 23:11:19 -0400 (EDT) (envelope-from rhh) Date: Sun, 19 Sep 1999 23:11:19 -0400 From: Randall Hopper To: Anthony Kimball Cc: hasty@rah.star-gate.com, van.woerkom@netcologne.de, multimedia@FreeBSD.ORG Subject: Re: tee-ing a sound stream Message-ID: <19990919231119.A1295@ipass.net> References: <199909190024.RAA29548@rah.star-gate.com> <199909190034.CAA02916@oranje.my.domain> <14308.15475.162264.375285@avalon.east> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <14308.15475.162264.375285@avalon.east>; from Anthony Kimball on Sat, Sep 18, 1999 at 08:41:48PM -0500 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anthony Kimball: |Quoth Marc van Woerkom on Sun, 19 September: |: |: Sounds like a generic audio-tee driver would make sense, that |: a program writes to, and that iself would pass on data to a file |: and a true audio driver. | |Having wanted to do this for some time, I have formed opinions about |how this should be done -- if you are interested: I think it should be |done as a device which passes calls on to the existing pcm driver. |Make an ioctl which allows one to pass a descriptor to the audio-tee |device. The ioctl should be sticky, i.e. should survive closes, so |that an aucontrol program can start/stop recording. Gut feeling tells me the kernel shouldn't be stream-writing files without a userland process sitting on a write() (failure/abort handling would be a bear). That's a daemon's job. FWIW, there's a similar situation with the way syscons handles mouse events which might apply here. Userland 'moused' sits on /dev/ttyd, pulling raw mouse events off the serial port and performing conversions. It feeds a canonical stream to syscons via ioctls, which in turn exposes these mouse events for arbitrary client (e.g. X server) consumption via /dev/sysmouse. However, mouse datarate is low compared with 44KHz 16-bit stereo (and then factor in newer soundcards with more than 2 channels of audio! :-) If too much for an ioctl (possibly not since that's how we're getting it down there in the first place), then maybe an mmap() region to pass data from the sound driver to userland would be better. Hmmm, or if we're talking about an executable dynamically linked with libc on an ELF system, what about just writing an LD_PRELOAD module which functions as an ioctl pass-through but, for audio ioctls, siphons off the audio data and does what it wants with it. Avoids having to mod the kernel, add kernel complexity, and having to pass the data twice across the userland-kernel boundary. This only works for dynamic ELF executables though. If you haven't used LD_PRELOAD, here's an example. Take an executable that's dynamically linked with libMesaGL.so (software OpenGL) -- say, 'xlock -- and you want it to use libGL.so (hardware OpenGL) instead. You can relink xlock with libGL.so, or (if it's dynamically linked with libMesaGL), just: setenv LD_PRELOAD /usr/X11R6/lib/libGL.so.1 xlock This `audio interception' sounds like a really cool feature though (snoop for the soundcard!) Good luck with it. BTW, Marc. GLX 3D is working very well on my Matrox G-200, thanks to http://www.freebsd.org/~3d and your package bundles. Having a blast over here with hardware accelerated 3D! I'll send details and benchmarks off-line when I cook some more ports and finish running them. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message