This plugin can measure RMS and peak of sound wave, do Fourier Transform, draw waveform, draw spectrogram.
All can be done separately for different channels.Yes, that sounds almost like description of AudioLevel. See list of improvements below.

Examples of usage
Plugin has lots of options, but if you only want to make something pretty, then you will probably be happy with default values, so it's actually very easy to use.
Here are two skins: Spectrum analyzer

AudioLevel doesn't have Spectrogram.
AudioLevel doesn't correct attack/decay values when sample rate changes.
AudioLevel doesn't do proper channel mapping. For example, it doesn't recognize 4.0 channel layout.
AudioLevel can't resample wave when sampling rate is high.
AudioLevel only allow you to declare one calculation of values for all channels. It doesn't allow you to define FFT for only one channel and RMS for one another.
AudioLevel calculates values differently:
RMS: AudioLevel doesn't have RMS. It calculates filtered squared wave value instead.
Peak: AudioLevel doesn't have Peak. It calculates filtered absolute wave value instead.
FFT: AudioLevel doesn't do proper normalization of the values. This leads to great change of values when size if changed. To be precise, FFT of size 16384 is 32 times bigger than FFT of size 16.
AudioLevel doesn't have cascaded FFT.
AudioLevel don't let you define relative size of the FFT, only absolute (this causes a big problems when sample rate of your sound card changes or when you want to distribute your skin).
AudioLevel doesn't correct zeroth value of the FFT.
Band: AudioLevel's Band feature always calculates sum of the FFT bins instead of average, which is not always desirable.
AudioLevel calculates bound using squared values of the FFT, which leads to incorrect filtering and (as far as I can tell) incorrect final values (they are much spikier than they need to be).
AudioLevel's Band doesn't blur values.

Plugin supports changing the majority of the options using !SetOption bang, but doesn't supportDynamicVariables=1because on each option change all values are reset!Skin using this plugin should have low update interval. Best 16-17 ms. At most 100 ms. Otherwise some (or most) of sound values will be lost. It's a defense against too computations heavy options. I don't know yet how to make this more convenient.

Question: How to set colors for bars? I know I can set the bar color in the 'bar' meters, but could not determine if your 'Colors:', as described in your documentation, is applicable?

I see the examples for Waveform and Spectrum, but could not figure out for each bar or all bars...

In the ini format of 'KeyWord=Value', having 'Values' with equal signs in them looks 'muddy' to me when trying to learn the syntax.
Is it possible to use a different designation symbol? Perhaps | like for InlineSettings?

Question: How to set colors for bars? I know I can set the bar color in the 'bar' meters, but could not determine if your 'Colors:', as described in your documentation, is applicable?

I see the examples for Waveform and Spectrum, but could not figure out for each bar or all bars...

Spectrum analyzer doesn't use my plugin's graphics, there are only Bar meters. And, well, bar colors are kinda hardcoded. Although it has different name, but it was just second test skin, so I didn't bother to make it comfy to change.
Colors, that are described in first post, are only applicable to images that my plugin draws, and for now it draws only waveform and spectrogram.

P.S. Spectrum is a set or current values of frequencies — 1D, spectrogram is values change in time — 2D.

In the ini format of 'KeyWord=Value', having 'Values' with equal signs in them looks 'muddy' to me when trying to learn the syntax.
Is it possible to use a different designation symbol? Perhaps | like for InlineSettings?

It sure possible to change symbol, but I'm not sure what will be better.
InlineSettings set one option at a time, so it uses | symbol to separate option name and option value.

My plugin is mush more like Shape meter: there are several my "options" in one Rainmeter option. Shape separates options by | and separates option name from option value by , while my plugin uses and = respectively. It makes sense to change my separation symbols to match those of Shape meter, but is it really needed?

There are already places in Rainmeter where you have to use = in the value of the option: in formulas, in String measures and meters. For example, it's perfectly valid to write Formula=1=SomeMeter in Calc measure.

key=value syntax, on the other hand, resembles Rainmeter options, so for me it's intuitive to use.

I'm not saying that I'm against changing my syntax, I just don't know what will be better.

Plugin updated to version 1.1.
This version includes compatibility breaking changes, so plugin name was changes to "AudioAnalyzer_1_1" to prevent problems with existing skins.

List of changes:
Fix: fft could not be used directly as source for spectrograms
Using | and " "(white space) as option separators instead of " "(white space) and =
All options are case-insensitive
BandAnalyzer removed, several handlers added to replace its funstions.
Add "RandomDuration" option to FFT.
Add check for reverse dependencies.
Add check for unused options.
Open sources.