www.pudn.com > lpc10-15.zip > contrl.fh

* $Log: contrl.fh,v $
* Revision 1.3  1996/03/29  22:05:55  jaf
* Commented out the common block variables that are not needed by the
* embedded version.
*
* Revision 1.2  1996/03/26  19:34:50  jaf
* Added comments indicating which constants are not needed in an
* application that uses the LPC-10 coder.
*
* Revision 1.1  1996/02/07  14:44:09  jaf
* Initial revision
*

*   LPC Processing control variables:
*
**** Read-only: initialized in setup
*
*  Files for Speech, Parameter, and Bitstream Input & Output,
*    and message and debug outputs.
*

* Here are the only files which use these variables:
* 
* lpcsim.f setup.f trans.f error.f vqsetup.f
* 
* Many files which use fdebug are not listed, since it is only used in
* those other files conditionally, to print trace statements.

*	integer fsi, fso, fpi, fpo, fbi, fbo, pbin, fmsg, fdebug

*  LPC order, Frame size, Quantization rate, Bits per frame,
*    Error correction

* Subroutine SETUP is the only place where order is assigned a value,
* and that value is 10.  It could increase efficiency 1% or so to
* declare order as a constant (i.e., a Fortran PARAMETER) instead of as
* a variable in a COMMON block, since it is used in many places in the
* core of the coding and decoding routines.  Actually, I take that back.
* At least when compiling with f2c, the upper bound of DO loops is
* stored in a local variable before the DO loop begins, and then that is
* compared against on each iteration.

* Similarly for lframe, which is given a value of MAXFRM in SETUP.

* Similarly for quant, which is given a value of 2400 in SETUP.  quant
* is used in only a few places, and never in the core coding and
* decoding routines, so it could be eliminated entirely.

* nbits is similar to quant, and is given a value of 54 in SETUP.

* corrp is given a value of .TRUE. in SETUP, and is only used in the
* subroutines ENCODE and DECODE.  It doesn't affect the speed of the
* coder significantly whether it is .TRUE. or .FALSE., or whether it is
* a constant or a variable, since it is only examined once per frame.
* Leaving it as a variable that is set to .TRUE.  seems like a good
* idea, since it does enable some error-correction capability for
* unvoiced frames, with no change in the coding rate, and no noticeable
* quality difference in the decoded speech.

	integer order, lframe
*	integer quant, nbits
	logical corrp

**** Read/write: variables for debugging, not needed for LPC algorithm
*
*  Current frame, Unstable frames, Output clip count, Max onset buffer,
*    Debug listing detail level, Line count on listing page
*

* nframe is not needed for an embedded LPC10 at all.

* nunsfm is initialized to 0 in SETUP, and incremented in subroutine
* ERROR, which is only called from RCCHK.  When LPC10 is embedded into
* an application, I would recommend removing the call to ERROR in RCCHK,
* and remove ERROR and nunsfm completely.

* iclip is initialized to 0 in SETUP, and incremented in entry SWRITE in
* sread.f.  When LPC10 is embedded into an application, one might want
* to cause it to be incremented in a routine that takes the output of
* SYNTHS and sends it to an audio device.  It could be optionally
* displayed, for those that might want to know what it is.

* maxosp is never initialized to 0 in SETUP, although it probably should
* be, and it is updated in subroutine ANALYS.  I doubt that its value
* would be of much interest to an application in which LPC10 is
* embedded.

* listl and lincnt are not needed for an embedded LPC10 at all.

*	integer nframe, nunsfm, iclip, maxosp, listl, lincnt

*	common /contrl/ fsi, fso, fpi, fpo, fbi, fbo, pbin, fmsg, fdebug
	common /contrl/ order, lframe
*	common /contrl/ quant, nbits
	common /contrl/ corrp
*	common /contrl/ nframe, nunsfm, iclip, maxosp, listl, lincnt