Re: RFC: GNOME 2.0 Multimedia strategy

[Havoc Pennington <hp redhat com>]

Seth Nickell <snickell stanford edu> writes:
> 
> Would you like to outline what you perceive as the differences between
> these two? Sound is a form of multimedia, and one of the concerns of a
> good multimedia framework should be I/O.
> 
> >From a more GNOME focused stance...shouldn't the user be able to assign
> "sounds" of any format to events? mp3, wav, midi, whatever? I don't see
> an inherent reason to limit ourselves to having a "sound I/O" api and a
> "multimedia framework api" unless we can't get the multimedia framework
> to have low enough latency.
> 

I think Jim explained the issue here extremely well - the "sound I/O"
api is more or less a portability layer across operating systems, and
allows multiple apps to share the sound device. That's it. This is a
small well-defined problem that benefits from a small, simple, single,
standard solution. That is you only want one of these. As soon as it's
big, complicated, or whatever, you will get design disagreements,
gripes about bloat, use of dependencies such as GObject, etc. and that
will lead to lots of people (not just KDE) implementing their own, and
it will lead to the thing being inappropriate for certain uses.  Also,
while we expect the sound I/O problem to remain essentially unchanged
over time, we expect the multimedia framework to do a lot of
evolution.

Anyway, it seems logical to have the portable but simple and low-level
way to say "here is how you access a sound device" and separate that
from the much higher-level UI framework. Just as it's logical to have
X separate from a toolkit. Imagine if it hadn't been, you'd still be
using Athena widgets.

Havoc