Linux-kernel mailing list archive 1999-41,: Re: Kernel OSS vs ALSA

# Re: Kernel OSS vs ALSA

Gorky (lk@orville.yi.org)
Fri, 15 Oct 1999 11:28:54 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alan Cox: "Re: Kernel OSS vs ALSA"
- Previous message: Alan Cox: "Re: Kernel OSS vs ALSA"
- In reply to: Alan Cox: "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/

- Next message: Alan Cox: "Re: Kernel OSS vs ALSA"
- Previous message: Alan Cox: "Re: Kernel OSS vs ALSA"
- In reply to: Alan Cox: "Re: Kernel OSS vs ALSA"