Re: GNOME 2 Sound Architecture and APIs?

[Elliot Lee <sopwith redhat com>]

On 12 Apr 2001, Miguel de Icaza wrote:

> > gnome-sound-list == place to discuss this issue
> > esound == bad
> > arts == bad
> > asd == possibly less bad
>
> I know why esound is bad, but I do not know why arts is bad.  Could
> you tell us more Elliot?

It confuses "sound server" with "media framework", and has a lot of
complex stuff that has no place in a sound server, e.g. MIDI sequencing,
special effects filters, and sound synthesizers. For crying out loud, it
has its own RPC system (MCOP), complete with IDL compiler...

This will make life less than optimal for GStreamer, Bonobo-Media, GMF, or
whatever else catches people's fancy, since they seem the right place to
put the fancy features and would have to fight with their aRts overlap. It
will also annoy people who want to have a simple sound server for use in
games or embedded platforms.

The only real reason people are agreeable to aRts is because KDE uses it,
and the god of desktop unification must be appeased. It does not sound to
me like most people have made coordinated efforts to determine what the
sound server requirements are, and whether aRts meets those requirements.
Take the time to convince yourselves that aRts is sound technically, as
well as politically, before jumping on the bandwagon.

asd purports solves the esound problems I know of in a more lightweight
manner, but does not appear to be completely finished yet. Correspondence
with the author may be wise.

Of the possible solutions...

esound risks to manage:
	. That it might detract from the attractiveness of the
	GNOME 2	platform.
	. That sticking it would waste a chance to find a superior
	solution.

asd risks to manage:
	. That it might not meet GNOME requirements for a sound server.
	. That it might not be finished/stable in time for the GNOME 2
	release.

aRts risks to manage:
	. That it might not meet GNOME requirements for a sound server.
	. That its requirements (resource-wise and dependancy-wise)
	  are excessive (even if the C API is used, the server is still
	  in C++, which so far has not been a requirement for GNOME).
	. That it may be selected as an acceptable sound server solution,
	but may wind up providing a media framework solution without
	being evaluated for this role.

-- Elliot
The truth knocks on my door, and I say
"Go away. I'm looking for the truth"
...and so it goes away.