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>> 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> 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> 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 -- 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