From my old "Picker and Voladj for Dummies" readme file:
The first parameter is the "factor per second".
This is then shifted left 16 bits and expressed as
an int. So to make voladj turn up the volume so
that the output is increased by a factor of two
every second, you set this to (2 << 16). Weird
things can happen if you set this very high or
very low, but it should be OK to give it sensible
values.
The second parameter is the minimum volume. It
attempts to make this the quietest thing you hear.
The units are sample magnitudes. If you set this
to 0, then none of the other parameters should
have any effect. If you set it to (1<<15)-1 then
in theory everything should be the same volume,
but more likely is that my log routines would get
confused. Best to stick with numbers less than
30000, I think.
The third parameter is the "headroom". This
attempts to reduce the number of times that a
hasty volume correction is needed to prevent
clipping. This is a fraction between 0 and 1,
shifted left 16 bits and converted to an int. Mind
you, it is currently ignored by the ioctl handling
code, so changing it currently has no effect. To
be nice, you should probably set this to 1 << 16.
The fourth parameter (real_silence) is the sample
magnitude below which we assume that there is no
listenable music present, so we gradually turn the
volume back down.
The fifth parameter (fake_silence) is the sample
magnitude that will get mapped to minvol. This
must be greater than real_silence. Hm, I'll have
to enforce that in the next version of my kernel
patch, I think.
If your samples are between real_silence and
fake_silence, then they are treated as if they
were of magnitude fake_silence.
Note:
Pass in the left shifted values (0x20000 for the
first parameter). In an attempt to make it a bit
easier to remember, sample magnitudes are just
raw, and (possibly) fractional values are
expressed as fixed point, with 16 bits to the
right of the point.
Editor's note: In the descriptions above, notations such
as "2 << 16" represent a Left Bitshift operation. For
instance, "2 << 16" represents 2 left-shifted 16 bits,
which works out to hexadecimal 0x20000 or decimal 131072.
In theory, you should be able to pass either the
hexadecimal values ( 0x20000 ) on the command line or their
decimal equivalents ( 131072 ). However, I've only tried
decimal, so I can't guarantee hex values will work. If
trying the hex values, make sure to precede them with the
"0x" prefix so that the software knows it's a hex number.
Note that you can use the Windows Calculator in Scientific
mode to convert numbers between decimal and hexidecimal if
you need to.