Provided by: siggen_2.3.10-4_i386 bug


       siggen.conf - the siggen configuration files




       As  from  siggen  version  2.3  onwards  a versatile configuration file
       scheme has  been  introduced.  It  allows  parameters  for  the  siggen
       programs  to  be specified either across the board, or specifically for
       particular programs.

       Three possible configuration files can be used:  a  LOCAL  config  file
       (usually  in  current  directory),  a  HOME config file in user's $HOME
       directory and a GLOBAL config file.

       All the programs are compiled with the names of the config files  built
       in.   The  filenames  are  set  in  the config.h header file and can be
       changed. The LOCAL  and  GLOBAL  config  files  are  specified  by  the
       settings of:

       LOCAL  #define DEF_CONF_FILENAME ".siggen.conf"

       GLOBAL #define DEF_GLOBAL_CONF_FILE "/etc/siggen.conf"

       And  can  be  set  to any file name or to NULL to disable the file. The
       HOME config filename is created using the  $HOME  environment  variable
       and  the  DEF_CONF_FILENAME  together,  i.e.  using the above, the HOME
       config file for a user whose home directory is at /home/jj, would be

       HOME   /home/jj/.siggen.conf

       The config files do not have to exist. If they exist and  are  readable
       by the program they are used, otherwise they are simply ignored.

       The  config  files  are always searched for configuration values in the
       order LOCAL, HOME, GLOBAL. This allows a scheme where the sysadmin sets
       up  default  config values in the GLOBAL config file, but allows a user
       to set some or all different values in their own HOME config file,  and
       to set yet more specific values when run from a particular directory.

       If  no  configuration  files  exist,  the  programs  themselves provide
       builtin default values (see config.h etc), and most of these values can
       be set by appropriate command line switches and flags.


       A  configuration  value  has  a  name  and  a value, and values for all
       programs are set by simply entering a line in  the  appropriate  config
       file   where  the  first  word  is  the  name,  followed  by  arbitrary
       spaces/tabs, followed by the value. The value is all the rest  of  that
       line.  e.g.  to  set the global default samplerate of 44100 samples per
       sec, the following line would be entered in the GLOBAL config file:

       SAMPLERATE     44100

       Config value names are case insensitive.

       A config value can be set for a  specific  program,  by  prefixing  the
       config  value  name  with the program name and a ':'. e.g. to specify a
       samplerate of only 8000 samples per sec for the tones program enter

       TONES:SAMPLERATE    8000

       in the relevant config file. If both lines above  were  in  the  config
       file,  all  programs  except tones would use a samplerate of 44100, and
       tones would use 8000.

       You do not have to specify  all  configuration  values  in  the  config
       files.   If a particular value is missing, the programs will simply use
       their builtin defaults (see config.h etc).

       Configuration values  set  by  command  line  switches  or  flags  take
       precedence over values in any of the config files.

       Beware the programs do not have their 'name' built-in, but use the name
              they were invoked by. So if you change the name  of  a  program,
              remember  to  change  the config file entries. However this does
              means that by using links to a program, it can be made  to  pick
              up  a  different  set  of configuration values, depending on the
              name it is invoked by.


       A sample config file is provided in ".siggen.conf" in the distribution.
       This  may  also  be  at  /etc/siggen.conf  .  Any line whose first non-
       whitespace character is a '#', is a comment line and is ignored.


       Not all of the siggen programs use all the values described here.   See
       the relevant man page for which values are used by which programs.

              In  all programs except tones and fsynth, channels specifies the
              number of output channels to use, i.e. 1  for  Mono  and  2  for

              For  tones,  channels  specifies the number of 'voices' on which
              tones can generate different waveforms before mixing  them  into
              the one output channel.

              For   fsynth,  channels  specifies  the  numbers  of  seperately
              configurable oscillators used to mix the single output channel.

              The Digital to Analogue Converter (or  PCM  or  DSP)  device  on
              which  to  output the generated samples. This must be a real OSS
              PCM device, otherwise the ioctls used will fail.

              The number of Audio Buffer fragments to configure in the driver.
              The  interactive  programs respond to changes made to parameters
              from the keyboard immediately, but data will be buffered in  the
              driver  in  the buffer fragments. If the amount of data buffered
              is too much then there will very  noticable  delays  before  the
              output  sound  is  altered. Against that, insufficient buffering
              may mean that there is not enough data buffered  for  output  to
              cover  the  time  when  other  processes  are  being  run by the
              scheduler. The programs set the buffer size to the nearest power
              of 2 to give aprox. 100millisecs of sound. Hence if FRAGMENTS is
              set to 3, there will be aprox. 0.3 secs worth of sound  buffered
              for  output. On a lightly loaded fast machine this, or 2, should
              be sufficient. To cover periods of  heavy  load  or  on  a  less
              powerful  machine  use  4  or  5.   But remember the interactive
              programs will appear sluggish in  responding  to  the  keyboard.

              The number of samples per second to use. If output is to the DAC
              then the DAC device is set to output samples at this rate.
              BEWARE: not all cards can support all samplerates. SoundBlasters
              are  fairly  flexible  in  this respect. Other cheaper cards are
              not. Indeed some cards can only handle a very restricted set  of
              related  samplerates  e.g.  11025,  22050,  44100 & 8000, 16000,
              32000, 48000. When writing to DACFILE all programs will  attempt
              to  set  the samplerate given, but use the actual samplerate the
              device used. Use the verbose command line flag to  check  actual
              samplerates used.

       Some common samplerates used are:

              is  the  samplerate used in the phone system with 8 bit samples,
              and is adequate for voice range frequencies.

              is the samplerate used in audio CDs

              is the samplerate used in DAT systems, I  think,  and  for  much
              professional kit.

              is also used, but I forget where, minidisc?.

              In  general, the higher the samplerate the larger the memory and
              processing requirement, but the higher the frequency  range  and
              the more accurate the signals generated.

              Number   of  bits  per  sample.  Only  two  values  are  allowed
              currently, 8 or 16.

           8  bit samples are unsigned,  with  decimal  value  128  being  the
              ┬┤zero┬┤ level.

           16 bit  samples  are  signed  little  endian values, i.e. the least
              significant byte comes before the most significant  byte  either
              in a file, or in the byte stream to an output device.

              If  samplesize if left completely unspecified, then all programs
              will attempt to do 16 bit samples to DACFILE, and if that  isn't
              possible  will do 8 bit samples. Or if writing to a file, 16 bit
              samples will be written.

              sets verbosity level.

           0  is quiet

           1  is be a bit verbose  (equiv. to -v  switch)

           2  is be very verbose   (equiv. to -vv switch)

              if set to a non-zero value,  then  the  VI  cursor  moving  keys
              "HJKL" are enabled.


       sgen(1), swgen(1)



       Copyright 1995-2008 Jim Jackson

       The  software  described  by  this manual is covered by the GNU General
       Public License, Version 2, June 1991, issued by :

              Free Software Foundation, Inc.,
              675 Mass Ave,
              Cambridge, MA 02139, USA

       Permission is granted to make and distribute verbatim  copies  of  this
       manual  provided  the  copyright  notice and this permission notice are
       preserved on all copies.

       Permission is granted to copy and distribute modified versions of  this
       manual  under  the  conditions  for verbatim copying, provided that the
       entire resulting derived work is  distributed  under  the  terms  of  a
       permission notice identical to this one.

       Permission  is  granted  to  copy  and  distribute translations of this
       manual into another language, under the above conditions  for  modified
       versions,  except  that  this  permission  notice  may  be  included in
       translation instead of in the original English.


       Jim Jackson