Provided by: siggen_2.3.10-11_amd64 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

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

              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 separately  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 noticeable 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

              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