Date: Sun, 19 Sep 1999 23:11:19 -0400 From: Randall Hopper <aa8vb@ipass.net> To: Anthony Kimball <alk@pobox.com> 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> In-Reply-To: <14308.15475.162264.375285@avalon.east>; from Anthony Kimball on Sat, Sep 18, 1999 at 08:41:48PM -0500 References: <199909190024.RAA29548@rah.star-gate.com> <199909190034.CAA02916@oranje.my.domain> <14308.15475.162264.375285@avalon.east>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990919231119.A1295>