On Tue, 11 Jun 2002, Terry Lambert wrote:

TL>Harti Brandt wrote:
TL>> TL>For a sound device, it would be nice if multiple instances to the
TL>> TL>devices were mux'ed.  I've had cases where the program I was using
TL>> TL>was using a smaller number that the total available channels, and
TL>> TL>it would have been nice if the next open instance got the remaining
TL>> TL>channels, rather than a "device in use" error.  You'd have to manage
TL>> TL>this by giving all remaining available channels to an opener, and
TL>> TL>then having them ioctl() the unused ones back (e.g. "allocate N"
TL>> TL>when there are M available, means "give M-N back").
TL>> That has also nothing to do with cloning. Look at the current pcm driver -
TL>> it just has a device entry per channel.
TL>A device entry per channel is a stupid idea.  It means that I can
TL>not write software to "open the sound device", I have gto write
TL>software to "open the *right* sound device out of N sound devices,
TL>so that I get the right channel".  It's a lot easier to just open
TL>the thing, than it is to teach every single piece of software that
TL>uses sound to do the "right" thing, and know how to do that.  If
TL>nothing else, it wil mean an incredible duplication of code in all
TL>sound using user space programs, and programs written by naieve
TL>programmers (yeah, I know -- like rattus giganticus, they don't
TL>exist, right) so that "if you want to run A and B, you have to run
TL>B first, because B doesn't know aboout anything but the first sound
TL>device".  This is just a recipe for disaster.

You just don't know what you are talking about. This is exactly the
difference between the current Linux sound (1 device) and FreeBSD (1
device/channel). In FreeBSD I can use N channels with different audio
formats and speeds, in Linux I'm stuck to using all the channels with the
same format. Try to write a conferencing tool, that has to work in a
heterogenous environment.

TL>> Where cloning could come into the
TL>> play is when more than one process tries to open a 1-channel device and
TL>> you want to mix the audio. As I said this would be a task of a layer above
TL>> the sound driver (just as X 'multiplexes' N processes onto one display
TL>> device). Unfortunately there is no good sound API up to now.
TL>If only you could differentiate open instances of the same device
TL>from each other, so that mixing would just be implied, and "just
TL>work"... if only the sound device were a *cloning device*.  8-).

Yes. And to open a file on disk I open /dev/da0s1a and then issue an ioctl
to get to the file (and a new device entry) and every disk driver
implements the file system. Every sound device writer writes all the
mixing and code conversion code into his driver... Just idiotic...

Mixing and code conversion is something you should do above the device
layer, just as you do TCP not in the network driver. What's the the API
that the user program sees from this generic layer is just a matter of
taste - cloning pseudo devices would be just fine.

harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
              [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to