home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / alt / lucidem / bug / 422 < prev    next >
Encoding:
Text File  |  1993-01-05  |  3.5 KB  |  72 lines
  1. x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 5 Jan 1993 17:53:10 EST
  2. Date: Tue, 5 Jan 1993 14:50:50 PST
  3. Message-ID: <9301052250.AA19147@thalidomide.lucid>
  4. X-Windows: Sometimes you fill a vacuum and it still sucks.
  5. From: jwz@lucid.com (Jamie Zawinski)
  6. Sender: jwz%thalidomide@lucid.com
  7. Subject: Re: Shouldn't the audio part be moved out of lemacs?
  8. References: <9301052055.AA18807@thalidomide.lucid>
  9.     <Pine.3.05.9301051642.D17104-c100000@trillian>
  10. Newsgroups: alt.lucid-emacs.bug
  11. Path: sparky!uunet!wendy-fate.uu.net!bug-lucid-emacs
  12. Lines: 58
  13.  
  14. In message <Pine.3.05.9301051642.D17104-c100000@trillian> Maximilian Ott wrote:
  15. >
  16. >> but the system doesn't provide such a program: you'd have to write the
  17. >> audio-handling code yourself, which is the hard part.  So why not just link
  18. >> it in to emacs directly and avoid the overhead of having to fork a process?
  19. > 
  20. > You have to read in the sound data at the beginning anyway. So you could
  21. > start the audio client by handing over a list of sound files and later
  22. > use symbolic names. The client then could preload the sound data.
  23.  
  24. You're still just talking about scenery.  The same work needs to be done; the
  25. same code needs to be written, since it doesn't exist yet.  Whether this code
  26. is linked directly into the emacs process or is running in some other process
  27. is largely inconsequential to the amount of work that needs to be done.
  28.  
  29. Making it so that the code can be in an external process is fraught with
  30. problems.  Doing it that way might build some false sense of generality, so
  31. that one could imagine that emacs was theoretically compatible with a number
  32. of different audio-server protocols, none of which exist yet, but this hardly
  33. seems worthwhile.
  34.  
  35. > The big problem I have with the current setup is that on a sun a program
  36. > needs exclusive access to the audio port. 
  37.  
  38. But this is a misfeature of the /dev/audio device driver, not of Emacs, right?
  39.  
  40. > I'm working on shared environments where I use the built-in audio port 
  41. > for audio-conferencing.  During the time another program is using the
  42. > audio port emacs is "dumb". (In fact I get a few error messages.) 
  43.  
  44. I don't think it's dumb.  Given that Sun's audio device can't be shared, what
  45. would you have emacs do when it wants to play a sound and the kernel won't let
  46. it?  Right now it prints a message in the minibuffer.  That message could be
  47. suppressed, but so what: the problem still exists, and it's not a problem that
  48. emacs can solve.  You want a better device driver.
  49.  
  50. > Don't get me wrong, it would be preferable to link in a library which
  51. > connects to an audio server ala "rplayd". But there is no standard, yet.
  52. > Forking a separate process gives you enough flexibility to do whatever you
  53. > want without needing to relink emacs everytime. 
  54.  
  55. The flexibility that *who* wants?  I think that the only people that this
  56. would benefit are those who are implementing new audio protocols, and the only
  57. real benefit to them is that they don't have to relink emacs to debug their
  58. code.  Maybe I'm misunderstanding what it is you're trying to accomplish?
  59.  
  60. > However, the issue of sound and X is another argument for separating the
  61. > sound so we can experiment with sound servers until we get that capability
  62. > in X. (As I said before "rplay[d]" is a good first step)
  63.  
  64. The emacs sound code and the emacs X code don't have anything to do with
  65. each other.  They never have.
  66.  
  67. The MIT people have said in no uncertain terms that audio protocols will
  68. never be a part of the X standard.  They're of the opinion that windows and
  69. sounds are orthogonal.
  70.  
  71.     -- Jamie
  72.