geek@mit-amt.MEDIA.MIT.EDU (Chris Schmandt) (03/13/90)
In article <4840@crltrx.crl.dec.com> jg@max.crl.dec.com (Jim Gettys) writes: > >Before being so unpleasently nuked last month, Olivetti Research in Palo Alto >was building a server called "VOX" which addressed these needs. > >I believe this is the correct course of action, until proven otherwise. And >there is no proof that audio is best done as part of the X server, at least >yet. As one of the people who worked on VOX (fortunately, at this point, as a consultant rather than an employee) I must second Jim's point. Personally I think even VEX may have gone too far, in terms of devices "beyond the screen", but that's another matter. VOX strongly resisted the temptation to put audio into the "window system", although we felt there was LOTS to learn and borrow from with the X model. You don't want to clutter X with audio responsibilities; managing audio is very different from managing more-or-less-static graphics. Similarly, the audio equivalent of the window manager is likely to be very different. However, the original poster was commenting on the need for synchronization across media. This is the best argument for supporting multiple media in a single server process. With multiple processes, coordination may become difficult, both because of operating system scheduling of the processes, as well as a potential need for server-to-server communication or double round trips to the synchronizing client. On the other hand, I would argue that the operating system most of us work on just won't support the fine grained sync necessary for, say, coordinating stimuli for an experiment, so kludging things on top of the X server is not the way to go. For much of the synchronization that application developers will require I suspect that processors are just getting fast enough that cross-media skew due to scheduling is likely to be minimal. There are all sorts of other solutions, involving scheduling events according to some external time base, using either absolute or relative time. But enough said for now. chris
rusty@garnet.berkeley.edu (rusty wright) (03/13/90)
I know this isn't very interesting, but has anybody done anything so that you can just do things like you can on the Macintosh; i.e. change the beep to play a short audio file? For example, I'd like to be able to use the xset command to be able to specify a file to play whenever XBell() is used. (Presumably the server would load the file into memory to cut down on disk access when beeping.) I guess so far this would only be possible on the SPARCstation 1 and the Next machine. -- -------------------------------------- rusty c. wright rusty@violet.berkeley.edu ucbvax!violet!rusty
marbru@auto-trol.UUCP (Martin Brunecky) (03/14/90)
Audio Extension, Display Postscript Extension, Image Extension, PEX
Extension .....
I believe we are at the point to reevaluate what are the extensions
for. Otherwise, the whole idea of the network transparency
will disappear in myriad of extensions, each available on one server
but not the others, with some servers becoming more complex that any
operating system.
It is time to start thinking about generic client-server protocol,
server-server protocols, and about dedicated servers.
--
=*= Opinions presented here are solely of my own and not those of Auto-trol =*=
Martin Brunecky marbru@auto-trol.COM
(303) 252-2499 {...}ncar!ico!auto-trol!marbru
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404 klee@wsl.dec.com (Ken Lee) (03/14/90)
In article <776@auto-trol.UUCP>, marbru@auto-trol.UUCP (Martin Brunecky) writes: > > Audio Extension, Display Postscript Extension, Image Extension, PEX > Extension ..... > I believe we are at the point to reevaluate what are the extensions > for. Otherwise, the whole idea of the network transparency > will disappear in myriad of extensions, each available on one server > but not the others You have a good point, in that too many extensions is probably not a good idea. I think, however, that no extensions is also not a good idea. Extensions provide powerful features that are generally inefficient or impossible to implement in the client. Of course, servers that do not support the extensions will not be able to interoperate with clients requiring them, but there are lots of other reasons a client will not work with a given server. Some servers won't have access to enough memory or to the right networks. Some won't be fast enough or have large enough screens. Others won't support the necessary visuals. That's life. The workstation market is not a commodity market. Limiting extensions to those that provide really useful functionality is probably a good idea. Making the specifications to the extensions open so that anyone can use them is another good idea. I think all the extensions mentioned above (except the audio extension, which I don't think anyone is really working on now anyway) are useful ideas with open specifications. PostScript is a de facto standard. PEX is an implementation of an ANSI standard. The image extension is still being studied, but there's probably a goal to make it compatible with the developing ANSI standard. The author of the X11R4 image extension proposal is also chair of the ANSI image processing standards committee. I think extensions do have a place in the X world. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
marbru@auto-trol.UUCP (Martin Brunecky) (03/15/90)
In article <3015@bacchus.dec.com> klee@decwrl.dec.com writes: > >You have a good point, in that too many extensions is probably not a >good idea. I think, however, that no extensions is also not a good >idea. Extensions provide powerful features that are generally >inefficient or impossible to implement in the client. Of course, .... ( I did not want to say NO extensions ).... > >Limiting extensions to those that provide really useful functionality >is probably a good idea. Making the specifications to the extensions >open so that anyone can use them is another good idea. I think all the >extensions mentioned above (except the audio extension, which I don't >think anyone is really working on now anyway) are useful ideas with open >specifications. > O.K. The problem I see is that all those really usefull extensions will make the server HUGE. Example is the XNeWs server, where people not using NeWs pay the penalty of the server support for NeWs, even though they don't use it. Another problem is extension loading/adding to the server. Most users will depend on vendor provided servers, with very little or no way to bind-in additional extensions, even though such extensions could be provided by the third party. The "big" extensions add a whole class of functionality. PEX, DisplayPostscript, XImage. The whole new dimension. Therefore, I would rather like to see such "extensions" as specialized servers, activated where needed, living in separate address space. Since many extensions demand really efficient access to the X server, sharing lots of X window semantics, they need an efficient, (shared memory based?), low level server-to-server protocol. On the other hand, there are extensions which are more "fixes" or minor enhancements to the core protocol. SHAPE is an excellent example. Such extensions deserve their place in the X server, and I don't object to it. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
evans@testmax.ZK3.DEC.COM (Marc Evans Ultrix Q/A) (03/15/90)
In article <780@auto-trol.UUCP>, marbru@auto-trol.UUCP (Martin Brunecky) writes: > > The "big" extensions add a whole class of functionality. > PEX, DisplayPostscript, XImage. The whole new dimension. > Therefore, I would rather like to see such "extensions" as > specialized servers, activated where needed, living in > separate address space. Since many extensions demand really > efficient access to the X server, sharing lots of X window > semantics, they need an efficient, (shared memory based?), > low level server-to-server protocol. > What if the *big* extensions used a shared library mechanism (assuming that the host OS supports the capability)? This would potentially eliminate most of the concerns that I see you raising. An example of one implementation which does this is DECs' VMS X Server. It isn't often that I recommend looking at a VMS system, but this is one thing that I think they have the right idea for. I must admit that having a full threads implementation on top of MACH could be real interresting, and would allow for some real flexability in the area of how an extension is fastened into the X server. Is anybody out there trying to put the server into the threaded and/or MACH environment? - Marc ========================================================================== Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)893-8481 Unix/X-window Software Contractor | 3 Koper Ln, Pelham, NH 03076 ==========================================================================
jg@max.crl.dec.com (Jim Gettys) (03/15/90)
You are missing the point. Audio has nothing to do with allocating screen resources. Only minimal coordination is actually needed with X. What is more, audio is a real time operation; it is very hard (read essentially impossible) to make real time guarantees in X. On grounds of keeping X from collapsing from over extension, therefore, unless some stronger grounds than just "it is a convenient server lying around", the burden of proof is on people to show why it can't be done as a seperate server. Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory
john@acorn.co.uk (John Bowler) (03/16/90)
In article <RUSTY.90Mar12155001@garnet.berkeley.edu> rusty@garnet.berkeley.edu (rusty wright) writes: >I know this isn't very interesting, but has anybody done anything so >that you can just do things like you can on the Macintosh; i.e. change >the beep to play a short audio file? For example, I'd like to be able >to use the xset command to be able to specify a file to play whenever >XBell() is used. I am also interested in this - if anyone is currently investigating an extension to allow sound samples to be downloaded to the server to replace the default behaviour of the bell I would be interested in cooperating. Acorn's hardware has the ability to deal output 8-bit logarithmic sound samples; our native operating system uses this to allow the bell to be reprogrammed in the way described and this sounds very popular :-). > (Presumably the server would load the file into >memory to cut down on disk access when beeping.) I guess so far this >would only be possible on the SPARCstation 1 and the Next machine. Plus ARM based machines - unfortunately the current release of our Un*x variant doesn't have the programmer's interfaces to drive the hardware. I do *not* think the server is a suitable place for general sound output - any program which does this will end up spending a large proportion of its time synchronising the output unless the kernel facilities provided are very sophisticated (large buffers, plus timing information, plus advice to the program about buffer status). In our interface the programmer just gives the kernel a sample and waits for it to finish - not much use if you want to draw wide intersecting lines with bevel joins at the same time :-) John Bowler (jbowler@acorn.co.uk)
nazgul@alphalpha.com (Kee Hinckley) (03/19/90)
In article <780@auto-trol.UUCP> marbru@auto-trol.COM (Martin Brunecky) writes: > O.K. The problem I see is that all those really usefull > extensions will make the server HUGE. Example is the XNeWs ... > Another problem is extension loading/adding to the server. > Most users will depend on vendor provided servers, with very > little or no way to bind-in additional extensions, even though > such extensions could be provided by the third party. ... Aren't all of these problems solved by simply having a server that dynamically loads in extensions when they are requested? -kee -- +-----------------------------------------------------------------------------+ | Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 | | 148 Scituate St. | Smart fax, dial number. | | | Arlington, MA 02174 | Dumb fax, dial number, | BBS: 617/641-3722 | | nazgul@alphalpha.com | wait for ring, press 3. | 300/1200/2400 baud | +-----------------------------------------------------------------------------+
black@yoyodyne..westford.ccur.com (Samuel (Opus) Black) (03/20/90)
In article <4872@crltrx.crl.dec.com> jg@max.crl.dec.com (Jim Gettys) writes: >What is more, audio is a real time operation; it is very hard (read >essentially impossible) to make real time guarantees in X. Gee, that's what they said about UNIX a few years ago. I'm currently working on RealTimeX, and we'll see what happens... - sam ------------------------------------------------------------------------------- Once you remove the absurdity from human existence, there isn't much left. __________ / _______/__ ...!{decvax,uunet}!masscomp!black /__/______/ / black@westford.ccur.com Concurrent /_________/ Computer Corporation -------------------------------------------------------------------------------
hvr@kimba.Sun.COM (Heather Rose) (03/20/90)
In article <4872@crltrx.crl.dec.com> jg@max.crl.dec.com (Jim Gettys) writes: >You are missing the point. Audio has nothing to do with allocating screen >resources. Only minimal coordination is actually needed with X. >What is more, audio is a real time operation; it is very hard (read >essentially impossible) to make real time guarantees in X. FYI: someone at Sun did do an audio extension on SparcStation1. They were showing it at the SUG, and giving away the sources. And the points Jim makes about "real time" are very real. The audio was often delayed and spotty thus making it a neat demo but not a realistic application. __________________________________________________________________ Heather Rose Window Systems Group internet: hrose@sun.com Sun Microsystems, Inc. uucp: ...!sun!hrose
don@CS.UMD.EDU (Don Hopkins) (03/21/90)
Date: 18 Mar 90 19:13:29 GMT From: snorkelwacker!spdcc!tauxersvilli!alphalpha!nazgul@bloom-beacon.mit.edu (Kee Hinckley) In article <780@auto-trol.UUCP> marbru@auto-trol.COM (Martin Brunecky) writes: > O.K. The problem I see is that all those really usefull > extensions will make the server HUGE. Example is the XNeWs ... > Another problem is extension loading/adding to the server. > Most users will depend on vendor provided servers, with very > little or no way to bind-in additional extensions, even though > such extensions could be provided by the third party. ... Aren't all of these problems solved by simply having a server that dynamically loads in extensions when they are requested? -kee Date: Thu, 4 Jan 90 14:35:13 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: bogus arguments, whether pro or con From: rws@expo.lcs.mit.edu (Bob Scheifler) Do I understand that NCR has a meta-extension for loading and unloading server extensions dynamically? It has a mechanism, yes. I don't know the implementation details. Is it in the form of a standard X extension that I could link into, say, an X11/NeWS server? There is no notion of a "standard X extension", in terms of implementation binaries or standardized internal interfaces, at least not right now. Or does it require server modification, and/or operating system support? I would say most interesting X extensions (3D, video, overlays, double-buffering, nonrectangular windows, input devices, shared memory) have required some amount of server modification and/or hardware/OS support.
bpendlet@bambam.UUCP (Bob Pendleton) (04/07/90)
From article <2045@acorn.co.uk>, by john@acorn.co.uk (John Bowler): > In article <667@bambam.UUCP> bpendlet@bambam.UUCP (Bob Pendleton) writes: > My argument (which may have got lost when the xpert<->comp.windows.x link broke > :-() is that it is only appropriate to provide a sound extension in X to meet > the needs of the X user interfaces. That is what I thought I was arguing for. Something more powerful than bell, but far short of performance quality. > (Haven't you ever been faced with > a situation where *something* just beeped, but you have no way of knowing which > of the many applications on the screen?) I sure have! What a pain. Sorry for the slow responce, our news connection has been down for awhile. Bob P. -- Bob Pendleton, speaking only for myself. UUCP Address: decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet X: Tools, not rules.