🚀 go-pugleaf

In article <52105@dime.cs.umass.edu>, hgschulz@cs.umass.edu (Henning Schulzrinne) writes:
> We are trying to use the audio capabilities of the Personal DECstation
> for real-time audio. Unfortunately, XMedia proves to be somewhat
> unsuitable for the task, since (among other reasons) we can't seem to get
> real-time play/record buffer position information or get notified (after
> less than 500 ms) how much audio data is available. Any suggestions on
> using DECstation audio (with or WITHOUT XMedia) are very much
> appreciated. (For the curious: we are implementing a real-time
> multiparty audio conferencing facility.)
> ---
> Henning Schulzrinne  (hgschulz@cs.umass.edu)  [MIME mail welcome]
> Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst
> Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249

I have a similar request. We are trying to port some audio software on the
Decstations, and are really dissatisfied with the overall philosophy of the
"audio server" approach. 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. The specs are not delivered with the hardware, and DEC suggest that
we have to go through studying the "DEC multimedia architecture" before even
trying to sing "Hello world" through the loudspeaker. We immediately concluded
that we wont buy any DEC machines anymore for multimedia applications, but are
still stuck with the one we already bought.

Does anybody have the spec of the hardware interfaces (/dev/lofi), or will we
have to reverse engineer them?

Christian Huitema

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).

>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.

> The specs are not delivered with the hardware, and DEC suggest that
>we have to go through studying the "DEC multimedia architecture" before even
>trying to sing "Hello world" through the loudspeaker.

The specs are delivered with the XMedia Tools Developers kit (*not* the specs
of the hardware, the specs of programming with the audioserver, which is
the lowest supported programming interface, very much like /dev/audio
is the lowest supported programming interface on SUN's).

> Does anybody have the spec of the hardware interfaces (/dev/lofi), 
> or will we have to reverse engineer them?

Basically all that interface gives you is a way to map all of the
hardware registers of the audio hardware in your address space, doing
that is a lot harder than using the audioserver.

If you any specific questions regarding a solution to your particular
programming problem, you may ask in the biz.dec.xmedia newsgroup.


		Burkhard Neidecker-Lutz

Multimedia Engineering, CEC Karlsruhe	   EERP Portfolio Manager
Software Motion Pictures		   Multimedia Base Technology
Digital Equipment Corporation
neidecker@nestvx.enet.dec.com

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

I agree XMedia audio does appear to be more complex than it
need be for some applications. However it doesn't *need*
X windows and Motif, look at the playstdin and record
binaries No X required, just a running audioserver.  
The problem I think they tried to solve is to provide an
audioservice for workstations that didn't support audio 
by providing a means of sharing one audi-capable workstation
with the client server architecture. However I can't think
of an application where I would want to have my audio remote
(i.e out of earshot)  RE the remote conferencing I guess
the audioserver does some of it for you, but I haven't
had time to do much to find out, and I don't know if it
would ever track any of the standards that are emerging

Pete Sykes	ICBL
		Heriot Watt University
		Edinburgh

In article <28817@sophia.inria.fr> huitema@mitsou.inria.fr (Christian Huitema) writes:
>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.
>
... (omitted) ...
>Christian Huitema

One more little detail: It doesn't work. While XMedia may be a superb
tool for playing sound bites for a multimedia kiosk or such, we have not
been able to get it (Version 1.1, that is), to work in anything
approaching real-time. We need to read audio data in 22.5 ms chunks for
delay reasons and the XMedia alib interface doesn't seem to be able to
handle that type of call frequency and leave processing power for other
system chores. I have heard claims that Version 1.1 would fix that, but
have seen no working code. We share Christian Huitema frustration. The
biz.dec.* newsgroup, btw, is no help to us - from what I can tell, it's
a commercial newsgroup not available on this campus. (I'll gladly be
convinced otherwise.)
---
Henning Schulzrinne  (hgschulz@cs.umass.edu)  [MIME mail welcome]
Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst
Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249