In message <Pine.3.05.9301051642.D17104-c100000@trillian> Maximilian Ott wrote:
>
>> but the system doesn't provide such a program: you'd have to write the
>> audio-handling code yourself, which is the hard part.  So why not just link
>> it in to emacs directly and avoid the overhead of having to fork a process?
> 
> You have to read in the sound data at the beginning anyway. So you could
> start the audio client by handing over a list of sound files and later
> use symbolic names. The client then could preload the sound data.

You're still just talking about scenery.  The same work needs to be done; the
same code needs to be written, since it doesn't exist yet.  Whether this code
is linked directly into the emacs process or is running in some other process
is largely inconsequential to the amount of work that needs to be done.

Making it so that the code can be in an external process is fraught with
problems.  Doing it that way might build some false sense of generality, so
that one could imagine that emacs was theoretically compatible with a number
of different audio-server protocols, none of which exist yet, but this hardly
seems worthwhile.

> The big problem I have with the current setup is that on a sun a program
> needs exclusive access to the audio port. 

But this is a misfeature of the /dev/audio device driver, not of Emacs, right?

> I'm working on shared environments where I use the built-in audio port 
> for audio-conferencing.  During the time another program is using the
> audio port emacs is "dumb". (In fact I get a few error messages.) 

I don't think it's dumb.  Given that Sun's audio device can't be shared, what
would you have emacs do when it wants to play a sound and the kernel won't let
it?  Right now it prints a message in the minibuffer.  That message could be
suppressed, but so what: the problem still exists, and it's not a problem that
emacs can solve.  You want a better device driver.

> Don't get me wrong, it would be preferable to link in a library which
> connects to an audio server ala "rplayd". But there is no standard, yet.
> Forking a separate process gives you enough flexibility to do whatever you
> want without needing to relink emacs everytime. 

The flexibility that *who* wants?  I think that the only people that this
would benefit are those who are implementing new audio protocols, and the only
real benefit to them is that they don't have to relink emacs to debug their
code.  Maybe I'm misunderstanding what it is you're trying to accomplish?

> However, the issue of sound and X is another argument for separating the
> sound so we can experiment with sound servers until we get that capability
> in X. (As I said before "rplay[d]" is a good first step)

The emacs sound code and the emacs X code don't have anything to do with
each other.  They never have.

The MIT people have said in no uncertain terms that audio protocols will
never be a part of the X standard.  They're of the opinion that windows and
sounds are orthogonal.

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Fri, 8 Jan 1993 20:51:19 EST
Date: Fri, 8 Jan 1993 17:42:51 MST
From: uranus!atlantis!wieman@uunet.uu.net (Trevor Wieman)
Subject: lucid 19.2 build problem (add'l info)
Newsgroups: alt.lucid-emacs.bug