Messages in this thread | | | Date | Fri, 15 Oct 1999 11:17:25 -0700 (PDT) | From | Gorky <> | Subject | Re: Kernel OSS vs ALSA |
| |
On Fri, 15 Oct 1999, Alan Cox wrote:
> > This has been a problem for me for a while, and I've been thinking about > > it quite a bit. I am quite interested in X-terminals, and most of these > > have NAS as their sound system. Unfortunately, there are about, oh, 2 > > Linux programs that support NAS. Nearly all of them just take over > > /dev/audio. > > Or use esound. The esound layer can also use dynamic linking tricks to run > most /dev/audio hoggers via esd. That suggests someone needs to beat esd into > supporting NAS.
There are a couple of problems I have with this:
- What about statically linked binaries? - How easily can esd be retrofitted to multiplex to multiple users? - I (and anyone else who wants userspace control) would have to use esd, and that means that any features I want have to be added to esd. In my case, all I really want is a daemon that sits there and distributes NAS requests across the network. I'd rather just have a simple interface to do this instead of having to pile it on esd.
If a device managing interface did exist, esd could use it, along with any other kind of sound daemon... And they would work flawlessly without change on top of it, just like any other program trying to use /dev/audio. The benefit to having an interface in place is that it can used in a huge number of ways that exceed just that which one program (eg esd) does, or can be altered to do.
The other benefits I see a device manager interface having for sound are:
- Input multiplexing--another issue with me personally. Programs for Linux (which seem to curiously all be designed with single-user environments in mind) that record sound could have their input drawn from network sources without having to know about it. - Weird situations, like having two sound cards and wanting to send the right speaker data to sound card A and the left speaker data to sound card B - Multiple daemons. I am connected to host C through host B, and I am on terminal A. I run a program on host C that wants to rplay to host B (it doesn't have access to terminal A), rplayd is running on host B but doesn't know about anything but /dev/audio. My audio device manager can potentially forward all that via NAS to terminal A.
Yes, all this stuff could be done by retrofitting esd. But that forces people to run one particular daemon, rather than having an interface for daemons, and allowing developers to just send their stuff to /dev/audio without a second thought. In my particular situation, I don't really want to run esd--I'd rather have a lightweight, custom program that does _only_ what I need it to do.
Some other things one could do with device managers in general:
- Framebuffer forwarding. Another thing I'd like in an X-terminal environment. A device manager could sit there translating framebuffer data to X protocol as it comes in, allowing people to run svga programs over the network (and on the same machine, in X) - Data encoding/processing. By putting a device manager on something like a serial/parallel port, you could encode, compress, translate, or whatever, all the data that passes through, all in userland. I know for a fact this would be useful for the particular printer situation I have (a rather crappy DeskJet) - Security. A line of defence beyond device permissions. - Flexibility. A device manager interface would allow for quite a spectrum of device managers for a large spectrum of devices. It would help solve my particular problem, and I think it would be useful in other situations as well.
Anyway, I am no expert, so I don't know whether or not it's worth it or how hard it would be to implement. Is there something there right now that can do this stuff? Is anyone else interested in this?
-gorky
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |