wrel20.me

来自「speech signal process tools」· ME 代码 · 共 978 行 · 第 1/4 页

.lp
The driver kits include a UNIX driver (with installation
instructions) and the following standalone programs: 
.nf
.sp .5
.ta 1.25i
  \fIwplay\fP \-	perform D/A conversion using DSP32 or DSP32C board
  \fIwrecord\fP \-	perform A/D conversion using DSP32 or DSP32C board
  \fIdspsgram\fP \-	compute spectrogram using DSP32 or DSP32C board
.fi
.sh 2 "On-Line Manual and Other Documentation"
.lp
The distribution includes on-line manual pages for \fIwaves\fP+,
the attachments, the auxiliary programs, and the file structure 
descriptions ESPS (5\-\s-1ESPS\s+1), FEA (5\-\s-1ESPS\s+1), FEA_SPEC
(5\-\s-1ESPS\s+1), and FEA_SD (5\-\s-1ESPS\s+1).  
.lp
The following new documents are included in this release: 
.sp .5
.nf
	"FEA_SD Files \- Feature Files for Sampled Data in ESPS"
	"Applications Note: Converting to and From ESPS Files"
	"Machine-Independent File I/O in ESPS"

.fi
.sh 1 "X WINDOWS VERSION OF \fIwaves\fP+"
.lp
Version 2.0 \fIwaves\fP+ has been ported to run under X Windows
(instead of SunView).  To do this, we used the XView toolkit under X11
R4.  Sun has released XView for Suns as a supported product and has
also placed the XView source code in the public domain.  We refer to X
Windows versions of \fIwaves\fP+ as \fIxwaves\fP+.  Owing to the use
of XView, \fIxwaves\fP+ uses the Open Look Graphics User Interface. 
.lp
Version 2.0a of \fIxwaves\fP+ will run on Sun SPARC CPUs with Sun
OpenWindows 1.0.1 or greater, on HP 300 systems with HP/UX 7.0, and on
Masscomp systems with RTU 5.0.  An ICCCM complient window manager
should be used with \fIxwaves\fP+, and some of the Open Look fonts are
necessary.  In particular, \fIxwaves\fP+ runs well under Sun's
OpenLook window manager (\fIolwm\fP).  On HP systems it runs under the
VUE window manager or their Motif window manager.  On Masscomp
systems, it runs under Masscomp's \fImwm\fP.  \fIxwaves\fP+ will also
run using a "vanilla" server built from the R4 MIT tape and it will
run with the window manager \fItwm\fP.  On all systems other than Suns
running OpenWindows, some of the Open Look fonts have to be installed.
We provide them under /usr/esps/xview \- see the README file there. We
also provide a copy of \fIolwm\fP.
.lp
In a number of cases we have tried, acceptable performance with
non-ICCCM complient window managers results from adding this resource
to the .Xdefaults file:
.nf

	XView.ICCCMCompliant: False

.fi
When running \fIxwaves\fP+ under Sun OpenWindows 1.0.1 (via the
\fIxnews\fP server), dynamic colormaps will not work properly unless
you define the environment variable USE_MIT_VISUALS prior to starting
\fIxnews\fP.  Otherwise, correct colors for any window will be seen
only when the mouse is in that window, and the colormap will change on
window entry and exit.
.lp
We will subsequently release versions of \fIxwaves\fP+ for other CPUs.
These will also use the Xview toolkit, which means that the Open Look
fonts and an ICCCM complient window manager will be needed.  We will
provide these as necessary.
.lp
The current release of \fIxwaves\fP+ includes X Windows versions of
the attachments \fIlabel\fP and \fIspectrum\fP; it does not include X
Windows versions of the attachment \fImarks\fP or the auxilliary
program \fIcmap\fP \- these will become available in a later release.
.lp
There are a number of known problems with \fIxwaves\fP+.  Among the
more noticable are these: Windows sometimes pop up in inconvenient
positions (especially with align-and-rescale operations).  Ghost
cursors and markers sometimes appear (just refresh the window).
Operations with the browser-menu can sometimes lead to core dumps.
Windows often are refreshed more than once when they are first
displayed, and occasionally at other times as well (especially on HP).
\fIXwaves\fP+ works well under the \fIolwm\fP window manager; with
some other window managers, windows come up with immense initial
sizes.  With certain combinations of clients and servers, digital
halftone displays appear with a reversed-sense for black and white
pixels (in this case, you can use the \fIwaves\fP+ global
\fIinvert_dither\fP to get the desired display).
.lp
On the HP300, the "waves+ manual" button does not work (from the
\fIwaves\fP+ control panel).  On Masscomps, external ESPS calls may
return early (e.g. spectrograms and any functions added via the
add_esps commands), in which case the display will be incomplete.  If
this happens, note the file name, kill the relevant display window,
and reload the file by entering the file name in the INPUTfile item on
the control panel.
.lp
With some window managers (e.g., \fItwm\fP on any system and \fImwm\fP
on Masscomps), windows have to be placed manually.  We consider
this to be a bug and are looking for a solution.
.lp
Many (but not all!) of the \fIxwaves\fP+ bugs reflect XView bugs.  In
general, we expect \fIxwaves\fP+ to improve steadily.  
.lp
If you see numerous X Window errors, and you are running under Sun
may also need to install the revised cgsix segment driver installed
(from /home/openwin/sys); this seems to be needed on certain
SPARCstation models, but not others. 
.lp
Your system should be configured with 25-30MB of swap space.  If
additional swap space is needed, the following procedure can be used 
on Suns (by a super-user): First, create a swap file with mkfile(1).  For
example, to create a 25MB swap file called "swapfile" in /home:
.nf

	%mkfile -v 25M /home/swapfile

Then, add an entry in /etc/fstab:

	/home/swapfile  swap  swap rw  0 0 

Then, reboot the system.  
.fi
.lp
On occasion, especially after frequent use, xwaves+ may fail with
various X Errors being reported in the console or other windows.  When
this happens, it is best to exit the window manager and restart.
.sh 1 "CHANGES AND BUG FIXES IN \fIwaves\fP+"
.sh 2 "Complex FEA Fields"
.lp
Complex data types are now supported in ESPS FEA files.  Previously,
FEA records were restricted to the fundamental types BYTE, SHORT,
LONG, FLOAT, and DOUBLE.  Support has been added for corresponding
complex types BYTE_CPLX, SHORT_CPLX, LONG_CPLX, FLOAT_CPLX, and
DOUBLE_CPLX.  Each complex type has a real and an imaginary part of
the corresponding integer or floating type.  For details see the FEA
man page FEA (5\-\s-1ESPS\s+1).  
.lp
\fIwaves\fP+ plots the real and imaginary parts of the elements of a
complex field as separate traces, each with a label consisting of the
field name, possibly followed by some bracketed subscripts, and
terminated with ".r" or ".i" (for "real part" or "imaginary part").
.lp
Note that ESPS FEA files with complex data can be created (from
headerless binary data) using the auxiliary program \fIaddfeahd\fP.  
.sh 2 "Multidimensional FEA Fields"
.lp
Multidimensional fields now have labels with multiple subscripts
rather than being treated as one-dimensional.
.sh 2 "FEA_SD Support"
.lp
In Version 4.0 of ESPS, the built-in file type for sampled data (SD)
has been replaced by a feature file subtype (FEA_SD).  Version 2.0
This has been done in a backward-compatible manor \- i.e.,
\fIwaves\fP+ will still read the old-style SD files (converting them
to FEA_SD on input).  We have also included conversion programs
between the old and new file types (\fIsdtofea\fP (1\-\s-1ESPS\s+1)
and \fIfeatosd\fP (1\-\s-1ESPS\s+1)).  For details about FEA_SD see
the man page FEA_SD (5\-\s-1ESPS\s+1).
.lp
Now that sampled data are stored as self-describing FEA files, such
data no longer has to be handled in general as a special case \- such
files can be read, viewed, and manipulated with \fIwaves\fP+ in the
same manner as any other FEA file.  This has several advantages.  For
one thing, it means that sampled data of any data type can be handled
(in previous versions sampled data was always converted to SHORTs on
input).  For another, FEA_SD files might have other fields besides the
sampled data itself ("samples"), in which case \fIwaves\fP+ can
display all of the fields in a single window.
.lp
The handling of sampled data is complicated, however, when the
optional DSP32 and DSP32C boards are used.  Because these boards are
limited to operating (for both spectrogram computations and D/A
output) on SHORTs, special handling is required for FEA_SD files since
they may contain sampled data of any data type.  (Note that this is
not an issue for AT&T SIGnal PCM files since they may only contain
SHORTs).
.lp
In this regard, the handling of FEA_SD files by \fIwaves\fP+ is
determined by a new global \fIfea_sd_special\fP.  The initial value
(on startup) of fea_sd_special is determined by the presence or
absence of a DSP board.  If the board is present, \fIfea_sd_special\fP
is set to 1; if it is absent, \fIfea_sd_special\fP is set to 0.
.lp
If \fIfea_sd_special\fP == 1, (the default if a DSP board is present),
data from the "samples" field in ESPS FEA_SD files are read in as
SHORTs (regardless of their external representation), and other fields
are ignored.  Values outside of the range (-32768,+32768) are clipped
to the extremes of the range.  When a signal is read in this manner,
\fIwaves\fP+ can use the DSP board for spectrogram computations and
D/A operations.  
.lp
If \fIfea_sd_special\fP == 0 (the default if the board is not
present), FEA_SD files are treated in the same manner as other FEA
files \- all fields are read and displayed, and no data type
conversions are performed.  In this case, whether or not the DSP board
is present, \fIwaves\fP+ cannot use it for spectrogram computations
and D/A operations, so the external programs determined by the
\fIwaves\fP+ globals \fIsgram_prog\fP and \fIplay_prog\fP are called
instead.  If these globals refer respectively to the ESPS programs
\fIsgram\fP and \fIwplay\fP (the default case), then the expected
operations and displays will occur, although with more of a delay than
occurs with the DSP board.  If one chooses to set \fIfea_sd_special\fP
== 0 when the board is in fact present, a useful option is to set the 
global \fIsgram_prog\fP to invoke \fIdspsgram\fP (which uses the
board) instead of \fIsgram\fP.  (But keep in mind that \fIdspsgram\fP
will convert the data to SHORTs before using the board, while
\fIsgram\fP works with FLOATs.)  
.lp
Note that it can sometimes be relatively time-consuming to read in a
non-SHORT FEA_SD file if \fIfea_sd_special\fP == 1, as the conversion
to SHORT (with limits checking) has to be done on every sample.
.sh 2 "Machine-Independent I/O"
.lp
In previous versions, files written by ESPS or \fIwaves\fP+ on one
machine could be read by ESPS program or \fIwaves\fP+ running on
another machine only if the two machines happened to have identical
numerical data formats and byte order.  This meant, for example, that
files from a Sun 4 could be read by \fIwaves\fP+ on a Sun 3 but not on
a Sun 386i or a DECStation 3100.  A goal for ESPS Version 4.0 and
\fIwaves\fP+ Version 2.0 was that differences in numeric formats and
byte-order among machines on the network be hidden from ESPS user
programs.
.lp
To meet the goal of machine independence, we defined an external ESPS
format that permits programs running on different machine
architectures to work cooperatively on the same files, and we revised
the ESPS file system accordingly to provide general support for
machine independent I/O (MIIO).
.sh 3 "NATIVE vs. EDR Format"
.lp
ESPS files in Version 4.0 can be in one of two format: NATIVE or EDR.
Data in NATIVE format files are written using the native numeric
formats for a particular machine.  Data in EDR (ESPS Data
Representation) format files are written in a standard representation:
floats and doubles are stored using IEEE standard 32 bit and 64 bit
floating point.  Integers and long integers are stored respectively as
16 and 32 bit twos-complement integers.  The byte type is stored as an
8 bit byte.  Character data is stored in ASCII with one character per
byte.  The byte order is that of the Motorola 680X0 processors.  The
ESPS external format essentially is similar to the Sun Microsystems
external data representation (XDR) format.
.sh 3 "I/O of ESPS Files"
.lp
ESPS programs and \fIwaves\fP+ will read files in either NATIVE or EDR
format (and also files from older versions of ESPS).  By default, ESPS
programs write files in the NATIVE format for the machine on which the