improve volume steps setting

[seife]

Right now, the hard-coded 21 volume steps allow for only a relatively coarse setting of volume.

I'd suggest a method Audio::setVolumeSteps(uint8_t steps) that sets the number of steps for the volume control.
This allows to set this e.g. to 32 (which is the same as many hardware volume controls provide) or to 100 (which maps nicely to a percent-based volume control).

Instead of the fixed pre-computed array of logarithmic-function multiplicators for each step, the coefficients can easily be computed by just using power-of-two (vol * vol) and the maximum of these (in the precomputed coefficients table this was 64) can also be easily computed at runtime (actually only once if the number of steps is set).

I implemented this extension in the https://github.com/seife/ESP32-audioI2S/tree/better-volume-steps branch in my fork.
This adds the following methods:

void Audio::setVolumeSteps(uint8_t steps);
uint8_t Audio::maxVolume();

maxVolume() returns the previous set number of volume steps so that e.g. a GUI can query what was set.
In theory, maxVolume() could be omitted, because the program that set the Steps could also just remember what it requested ;-), but I found it handy to abstract this knowledge from the caller.

The implementation in my better-volume-steps branch also gets rid of float arithmetics in Audio::Gain() and simplifies (IMO, that's certainly debatable) that code.

Note that the code in better-volume-steps is 100% backwards compatible, as long as setVolumeSteps() was not called, it will use the same steps as before.

[schreibfaul1]

I'll see about that in the next few days. It is difficult to understand without a description or background. The 22 volume steps are intended for touchpads, for which it is completely sufficient.

[seife]

I pretty extensively tested that nothing changes if the setVolumeSteps is not used.
I actually use this also to reduce the number of steps if external volume control is available (es8388 has 96 volume steps in the mixer, so I use software volume only after i reduced the mixer volume to the lowest setting, for additional 4 steps until "mute"), which gives 100 steps ("percent like") in total.

So this is an extension to the original API but the original can still be used.
We could in a later step get rid of the volumetable[], but we'd need to check if setVolumeSteps(21) actually behaves identical to the original code from a listening perspective.

[seife]

if you use setVolumeSteps(21), the steps will differ.

I normalized the calculated steps to maximum value of 64 (as in the original volumetable[] array) and the result is:

step current correct
 0:     0     0.000
 1:     1     0.145
 2:     2     0.580
 3:     3     1.306
 4:     4     2.322
 5:     6     3.628
 6:     8     5.224
 7:    10     7.111
 8:    12     9.288
 9:    14    11.755
10:    17    14.512
11:    20    17.560
12:    23    20.898
13:    27    24.526
14:    30    28.444
15:    34    32.653
16:    38    37.152
17:    43    41.941
18:    48    47.020
19:    52    52.390
20:    58    58.050
21:    64    64.000

Note that my code does not use a max value of 64, but instead calculates the attenuation without rounding so that the fractions above are actually calculated correctly using integer-only math.
The current code is weak (not following the proper logarithmic volume curve) especially with low volumes (which is how I noticed when listening with headphones at low volume ;-))
It is probably not noticeable with the higher volume settings (above step 12 approximately), but with lower volumes it clearly is.