🚀 go-pugleaf

In article <1992Sep7.152506.24097@PA.dec.com> Burkhard Neidecker-Lutz writes:
> In article <28622@sophia.inria.fr> huitema@mitsou.inria.fr (Christian Huitema) writes:
< 
> >Hell, we wanted a simple analog/digital converter
< >that would enable us to input output voice and we are delivered a "sound
> >processing system" that cannot work without being intertwined with X-Window
< >and MOTIF. 
> 
< Of course the audio software can be used without X and Motif if you wish
> so, that is the whole point of using a separate audio server in the first
< place. I agree that the toolkit that is shipped with XMedia Tools in Version
> 1.1 in fact *is* linked to X and Motif, forcing you to use the somewhat
< clumsier Alib interface instead. But it certainly is doable and the
> XMedia Tools Developers Kit certainly comes with complete sample programs
< that do all of this (without X).

Except one little detail. The first thing that "audioserver" does is to try to
connect to the local X server, and it aborts if it cannot.

> 
< >We are trying to port some audio software on the
> >Decstations, and are really dissatisfied with the overall philosophy of the
< >"audio server" approach...
> 
< Well, let's see what SUN has to say about this (from the man page of audio(4)
> on my SparcStation):
< 
>   FUTURE DIRECTIONS
<      Workstation audio resources should be managed by a networked
>      audio  server,  in  the  same  way that the video monitor is
<      manipulated by a window system server.  For the time  being,
>      we  encourage  you  to  write  your  programs  in  a modular
<      fashion, isolating the audio device-specific  functions,  so
>      that they may be easily ported to such an environment.
< 
> which is to say that even they see the shortcomings of using the /dev/audio
< approach to things. Your reaction is similar to the shock that people get
> when they move from a PC where you own the whole screen to a windowing
< environment such as Windows or X11, where a lot of simple things (like
> drawing a line) can become seemingly buried under a lot of surrounding
< code. The lack of a X-independent toolkit admittedly is a shortcoming of
> the current XMedia offering, but then SUN doesn't offer anything in that
< space at all.

There is a very very big difference between "X window" and "audioserver", and
that is called "standards". I have nothing against using the X protocol, and
in fact our videoconference server does run over X. I consider this as a plus,
as it gives us portability. "Audioserver" does not gives us any such
portability. It is not the result, as X, of a joint project involving several
computer makers and one of the world best independant labs; it is not, as X,
the natural follow-on of several independant attempts; it does not come, as X,
at a time were the market is ripe for standardization. On the contrary, it
would pretty much look like an half cooked equivalent of the early "SunTools"
windowing system: proprietary, non portable, trying to lock in the users.

It should also be clear that the parallel with X-window is only valid up to
some limits. It make sense to couple X and voice if the voice is used as a
"display device", i.e. if loudspeaker and mike are used as part of the user
interface. There are many sound processing applications where this is not
true, e.g. a background phone responder, a music synthetizer, a recording
device, a remote microphon... In all these cases, you need the basic interface.

The "/dev/audio" interface of SUN is way simpler than the "audioserver" of
DEC. It all stands in a few parameters: 8KHz, 8 bits, uLaw, open in "Write"
mode to speak, open in "Read" mode to listen. In the absence of standards,
simplicity is a real advantage. For one thing, it allows you to develop
different "audioserver" approaches; it also allows us to port these servers
easily on various platforms. Note that this is very easy to develop, given the
simplicity of the spec and the relatively low degree of system integration
required for an audio channel -- there is no question of dual ported image
banks here, but merely a serial byte stream!

I observe that DEC does not provide me with any such simple interface. It looks
like DEC at first did not believe in multimedia interfaces for the work
stations: the 5000/200 were shipped without any audio interface. Then, in a
typical late-comer approach to the market, they thought they would do much
better than simply following the architecture proposed by SUN, Sony, HP and
the like, and came out with their "architecture" -- a very good one from their
point of view, as it was "invented here". I stand by my opinion, and will not
buy any DEC machine anymore until that problem is solved.

Christian Huitema