For volume (and master_gain) controls, especially those of Port lines, it is not clear wether they have a linear or logarithmic behaviour. This is unacceptable, because application programmers need to know the characteristics. For the behaviour presented to the user, there is not much choise: The amount of way on a volume slider has to match the subjective impression of volume, which enforces a logarithmic behaviour. So if the control exposes a linear behaviour, the application has to do the job of logarithmising the characteristics. For ease of use, it would be best to specify that volume controls are always logarithmic. But at least there must be a way for an application program to find out if a control has linear or logarithmic behaviour. One possible means to do that is using the "unit" property of the respective FloatControl.

Additional facts that support the "always logarithmic" approach are:

- in almost all cases I know of, the hardware of mixer chips work with a logarithmic scale (linear is clearly ruled out if a mixer register has only 4 or 5 bits (16 or 32 different values) for volume). So since the hardware is logarithmic, and the user interface is logarithmic, it makes a lot of sense to keep values logarithmic in between. Surely it is possible to linearise values and logarithmise them back again. However, rounding error will sum up (actually, multiply up).

- The precision value of FloatControls makes no sense if a logarithmic value is linearized. Typically, hardware registers allow for values 0 to 31, with each step meaning, for instance, 1.5 dB. While it is typically not possible with OS APIs to find out how big the steps are, it is a safe assumption that they are equal spaced in terms of dB (i.e. in a logarithmic scale). However, if these logarithmic values are linearised, the precision value looses its sense: the equal spaced logharithmic steps map to non equal spaced linear steps. The only (hacky) solution to make use of the precision value is to divide the linearised range by the number of steps allowed in the hardware. The application program can reconstruct the number of steps when logaritmising back. However, this is highly prone to rounding errors, and well, the actual value of precision is always wrong. All this can be avoided if values are passed unscaled and unlinearised to the application program. Then, the application program can safely detect the real hardware resolution of the volume value.