Re: sound and gnome ?

[Tom Tromey <tromey creche cygnus com>]

DrMike> The initial goal needs to be designing the gnome API so gnome
DrMike> apps are independent of the hw layer we use.

Yeah.  But arguably that is what something like NAS provides, right?
It is precisely an API that is independent of the hardware (and
network).

Do we really need another abstraction layer on top of this?  I can see
that we might want one if we were really unsure of which protocol we
wanted to use, or if we wanted to support several protocols.  I don't
know if either of these is the case.


DrMike> GNOME
DrMike> Event Manager-
DrMike>               \
DrMike>                + Gnome Sound API -> HW Abstraction (NAS?) -> Sound HW
DrMike> GNOME         /
DrMike> Application  -


I'm largely in agreement here.

I think there are two kinds of programs:

1. Programs that need sound.  Games, music programs, mixers, etc fit
   in here.

2. Programs that might want to use sound as an "extra".
   Basically everything else fits in here: editors, xterm, etc.

Programs in category #1 need direct access to the Sound API.

Programs in category #2 don't necessarily need to know that sound
exists.


DrMike> The GNOME event manager will accept triggers (help me here
DrMike> elliot if I'm lost) and will handle mappings to the associated
DrMike> action. There will be standard triggers than applications can
DrMike> activate, like 'out of disk space'.  The event manager will
DrMike> have actions which can be user configured, perhaps to play a 3
DrMike> stooges wav file. The Gnome Sound API needs to be able to play
DrMike> a standard sound file in that case.

I think we should view the event manager as a low-level bus.  It
accepts events, and then redistributes them to the objects that have
registered an interest.  I think the event manager shouldn't have any
direct knowledge of sound, because it is a generic service that will
be used for other things.

Instead, there should be a program that listens to the events coming
off the event manager, and translates the appropriate ones into sound.
For instance, it might see an event indicating "the build failed", and
turn that into a buzzing noise.  Or it might see a "talk session
requested" event, and turn that into a phone ringing.  Or whatever.

The Gnome Sound API wouldn't need to be able to play standard sound
files for this to work.  That would be the job of this special program
-- it is in category #1.


More exposition on events and such: the way I see it, an "event"
should just be a string (the name) and some piece of associated data.
The names of events will be defined solely through convention.  We'll
document all the ones our code generates/supports, but any program
could add a new event at any time.  (Maybe this is too low-tech?  I
personally like low-tech solutions, but I realize they don't match
everybody's sense of style.  Feel free to chime in.)

The event->sound program can work by doing pattern matching on event
names.  Maybe something more complicated would be required (e.g.,
something to actually look inside the event data to make decisions),
but that can be addressed entirely within this program.


One nice thing about removing decisions about sound from individual
applications is that we give the user more power to control the use of
sound (provided the applications generate events in all the
interesting cases).  For instance, a user who doesn't like sound could
turn it off in one place.

Tom