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