Messages in this thread | | | Date | Fri, 15 Oct 1999 11:28:54 -0700 (PDT) | From | Gorky <> | Subject | Re: Kernel OSS vs ALSA |
| |
On Fri, 15 Oct 1999, Alan Cox wrote:
> > - How easily can esd be retrofitted to multiplex to multiple users? > > esd already mixes and multiplexes. Thats why ever gnome app can go ping and > boing at the same time.
What I mean is can esd send one set of sounds out to one user's terminal and another set to another user's terminal? :) I know it doesn't do NAS yet, but that's what I meant.
> > 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 > > esd is a protocol and a daemon.
So's NAS, I need NAS :) Some people need rplay. Some people just need /dev/audio.
> > 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. > > I don't follow you. How can you multiplex audio with other people if you only > want to do the bits you need. What about the bits _THEY_ need.
What I mean is that by providing an interface as opposed to a policy you give people the option of using whatever mechanism they like--esd, NAS, rplay, or their own thing--and they'll all work together, AND they can do stuff like what I want to do if they want. I am not suggesting forcing people into one solution. Perhaps an interface like this would be beneficial though?
> > - 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) > > Fix svgalib to do X11. Solving the problem is a lot more efficient than > handling the mess if you dont.
I don't particularly like svga programs and it's not critical to me that they work. I wouldn't go write this program even if the interface I'm talking about _were_ in the kernel :) But if I were I'd rather write a program to do it that runs outside of svgalib. That would save me the trouble of recompiling all my svgalib programs and figuring out a way I could still use them to do what they normally do.
-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/
| |