No subject

applications to use each other as sources as sinks, basically virtual
sound cards.  That way a drum machine can write to a virtual sound card,
and that virtual sound card can then be used as a loopback input to
another program, say a sequencer or mixer.

It seems to me that we might want to make this part of the requirement for
a good sound server, with the understanding that it should be simple, yet
still be able to route any application to any other.

> A year or more a ago, I tried to poke people into working on this problem,
> but didn't get critical mass to make progress.  Keith Packard and I set
> up a "soundserver at xfree86.org" mailing list to try to get it going, but
> did not really advertize it much: neither of us has had time to do more
> than comment on what little traffic there has been (both of us have built
> audio servers).  What is really needed is a good architect with enough
> time on their hands (which leaves Keith and I out, being too busy already).
> Maybe we should try again to get things moving in this area.  But it really
> needs at least one full time really good person to make good progress,
> I suspect.  There is alot of code available to help the problem (all of
> the above list's code is available), but the design has to be done and
> a real artifcat built.
>
> That being said, gstreamer, from what I can gather, though I haven't studied
> it carefully, looks like a reasonable library to help the apps do what
> they need and is a strong candidate for Gnome's need for 2).  But I don't
> think it, itself should have to deal with the hardware abstraction and
> network issues on top of everything else.  The problems are enough different
> that trying to mix both into one is likely to fail, and won't withstand
> the test of time; I can guarantee we'll learn lots more about signal
> processing over the next decade.
So, what I proposed to the GStreamer list, and will outline quickly here
(and expand on soon) is that the 'sound server' actually be set up like X,
with the core of the system being a wire protocol, and transports for said
protocol (which is complicated a bit by the fact that there's control and
data flow with different properties, but XShm is the same thing...).  The
software piece would be an xlib-like library that only deals with the
protocol/transport-specific bits of the soundserver API.  A program can
then be written to do the esddsp trick, gnome-libs can have a simple
interface built into it, and the sound server can be written with anything
you want.

One wishlist item is that one be able to gnome_play_sound("bleep.mp3").
The protocol should be able to handle some variance of data type, not just
raw audio (IMO).  This would make GStreamer an ideal basis for the sound
server itself (NOT the clients, unless they need that complexity, which
should be provided via some other interface to the same sound server
process, probably CORBA).

I gotta go, I'll explain more when I get back.

TTYL,
    Omega

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_