Re: GNOME 2 Sound Architecture and APIs?

[Elliot Lee <sopwith redhat com>]

On 12 Apr 2001, Miguel de Icaza wrote:

> We could ship applications with an audiolibrary that would talk to the
> arbitration daemon.  If the system audio supports multiple opens on
> the dsp, then the daemon gives us a pointer to it `open /dev/dsp', if
> not, then we get a handle to the daemon mixing `open
> /tmp/audio-socket'.  For applications opening /dev/dsp, they would use
> their in-proc library to do any kind of pre-processing that they were
> expecting the daemon to do.

I am in favor of an approach like this that minimizes the overhead of
using sound when possible. However, there are a few questions not
addressed here:
	Q. How would network-transparency be addressed?
	A. Most likely, talking to a local sound daemon (for
	   hardware only capable of a single stream) would be the
	   same as talking to a remote sound daemon.

	Q. How would sound events be handled?
	A. Currently esd stores the sound samples and plays
	   them back at the request of applications. One possible
	   solution is having gnome-session (or another per-session
	   process) perform this duty, and then devise a way for
	   applications to easily talk to this process.

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