Re: Multiple applications using sound drivers?

Tuomas Heino (iheino@cc.hut.fi)
Sun, 28 Feb 1999 10:46:09 +0200 (EET)


On Sun, 28 Feb 1999, Nathan Hand wrote:

> On Sat, 27 Feb 1999, Joe Votour wrote:
>
> > Having used UNIX for a few years here in university, I am fully aware of
> > devices being locked while they are in use. My distributed networks class has
> > taught me the importance of that (we tend to do a lot of programming
> > assignments dealing with file locking and IPC messaging).
> >
> > However, there is a feature that I wish Linux had that Windows (shudder) offers
> > - multiple programs accessing the sound card at once.
>
> Windows does not have this feature. The Windows sound driver can be
> held by a single process, just like the Linux sound driver.
>
> The difference is for Windows you write to the MCI API (or whatever
> it's called this week) and it transparently mixes other streams for
> you, before delivering it to the sound driver.
>
> On Linux we have something similar. It's called the ESD, and if the
> sound application community stopped using /dev/dsp directly, and in
> the interests of users started using ESD, we'd all win.
>
> ESD even includes a wrapper script that fakes /dev/dsp for all your
> old legacy applications. You can get the functionality you want now
> with no major effort on your part.
>
> ESD has other potential benefits, including removing bloat like the
> softoss wavetable driver and putting it in user space where it more
> rightly belongs. ESD can also transfer sound streams over the net.
>
> Despite this gushing about ESD, it does have flaws, but Linux would
> be better off fixing ESD and using it rather than changing the UNIX
> open() semantics just to make badly behaved sound apps work.
>
> Take note that the exact same problem exists for a number of rather
> important subsystems, including libggi vs X, and gpm vs X, and sane
> vs sg. Some userland peace treaties would solve a lot of problems.

Now... after all these shameless plugs about ESD one question remains:
Where to get more info about it? ;)
... and while you're at it how does it interface with ALSA etc? ;)

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