Re: More fun with sound (was GNOME CVS: libgnome martin)

[Tim Janik <timj gtk org>]

On 10 Aug 2001, Joe Shaw wrote:

> On 09 Aug 2001 20:13:41 -0400, Havoc Pennington wrote:
> > I don't see why we have to "bless" something before we are ready; apps
> > that want sound now can pick the esound lib or CSL or as they like, 
> > and then once we see a clear de facto standard or really do our
> > homework, we can "bless" one in GNOME 2.0.1 or 2.2 or whatever is
> > appropriate at the time.
> 
> Ugg. One of the nice things I remember about esd (way back when I used
> it) is that it did mixing for you, since a lot of cards couldn't do it
> in hardware. Many still can't. That way if I were listening to oggs in
> xmms I could still hear the bing bong when I got some email. Asking
> application developers to pick any old sound API they want sounds like
> it'll be a real pain from a support standpoint ("Why can't I play mp3s
> while my <insert random application> is running?").

"because you're not running a sound mixing daemon. run a program likae aRts
or esd <puke> in the background and applications will produce sound concurrently"
would be an apropriate answer. of course there should be some control-center
tihngy to offer automatic running of a sound daemon if it finds one present
on the system.

the necessary stuff to get this going, i.e. apps that just want to play
sounds through a /dev/dsp like backend, is what CSL meant to adress.
it's sole purpose is to wrap all the different APIs that sound daemons/devices
provide. it does so without introducing any further dependancies (it doesn't
even require GLib and is easy to integrate via .ps file, so properietary apps
could use it as well).

> An argument against it, but along the same lines, is we should hold off
> so we could play nicely with KDE's sound system if we can, ala the
> .desktop format and the window manager spec.

there's freaking much religion going on in the sound camp, basically because
very non-naive sound beginner starts out with coding his own daemon, and
different sound programmers set different priorities in their backend/daemon
implementations, e.g.:
a) joe user just wants window manager plings mixed into his mpg123/xmms output
b) gamers want soft-realtime, i.e. bangs and booms being played seemingly
   instantly in response to what happens on screen
c) studio-type of guys want hard-realtime "this sample has to be played exactly
   when a MIDI_NOTE_ON arrives with less than 5ms latency"
d) control/featuritis freaks can't live without putting a reverb or echo on top
   of xmms' output
e) network fetishists need their midi-tracker and fftscope to run on a different
   machine than the sound daemon
f) the atk guys want to mix speech-synthesis output on top of what's played and
   need future sample cancellation
etc, etc...

at this point, we're here:
* KDE has a full-featured sound system with a nearly-all-doing background daemon
* GNOME has nothing besides some really cruel legacy esd hacks that everybody
  wants to see removed

in order to avoid yet-another-long-leading-nowhere-flamage-thread, i think we
should go with the least common dominator that everybody needs and which is
still open to any of the above a-f featuritis, while being pretty easy to
accomplish in the time remaining:

for every GNOME app, offer a /dev/dsp alike interface that works on sound devices
portably and supports daemons when present.
that gets us (a), most of (b) and (f). if people need any of full (b), (c), (d)
or (e), they can run a daemon suiting their needs and apps that support that
daemon in full-fledged mode, while still having naivly sound-aware GNOME apps
automatically integrate with it.

all that is required is a /dev/dsp wrapper that hides /dev/dsp, /dev/audio,
aRts, esd, whatever backend-APIs.

and yes, i say it again, that wrapper is exactly what CSL was initiated for.
in fact, i don't see much use in persuing CSL development if we don't deploy
it as a standard component in GNOME, because:
1) BEAST/BSE (my personal sound pet) already knows how to operate /dev/dsp
2) KDE doesn't need CSL because they got everything needed from aRts already
3) i don't run proprietary software in general, so i could care less if
   proprietary software vendors use CSL, platform-dependant raw audio device
   backends or burn their samples on CDs shoot them moon^H^H^H^Hmarswards

-end-of-supposedly-passionless-ramblings-

> 
> Joe
> 

---
ciaoTJ