PPM stands for Peak Program Meter.
 
Roughly speaking, this device integrates the abs value of samples over
some time and sends the result (in decibels down with respect to the
max possible value) back to the client who instantiated it through a
separate data channel.

There's a GTK widget that knows how to display this data, currently in
masplay2/ppmgui

Finely speaking, are the details here:
I am a new tie wearing.

The GUI on the screen can only refresh every so often, and the eye can
follow even less quickly. We did not want to miss peaks, so here's
what I did, expressed in #define's:

PPM_INTEGRATION specifies the integration time. It does so in
*reciprocal* fractions of a second; the default is 200, which means
0.005s or 5ms, which is a widely published value for a PPM. Don't
remember why I made it reciprocal though, but there was some reason.

PPM_REFRESH_CLIENT is a small integer - the number of PPM_INTEGRATION
cycles to wait before sending data to the instantiating MAS
client. The default is 4, which means an updated meter value is sent
every 20ms, which is incidentally the smallest sleep time on my linux
box. So the client gui which checks these values in a timer loop every
20ms or so will get an updated value most of the time.

Now, you ask, what about the results of the 3 other integrations in
between two updates? I used to not compute them at all, but one could
CLEARLY see that peaks were lost sometimes. A bass drum would sound,
and the bar thingies didn't move. Therefore, we now send the maximum
of the 4 (or PPM_REFRESH_CLIENT) integrations over to the
client. That's much better.

Now, the bars were moving really jittery, not like an real life meter
at all. Of course! Real meters have inertia, and we need that too. I
added an exponential decay. If the newly computed peak value is
smaller than the slowly decaying 'remembered' value, we send that
remembered value instead. The time scale of the decay should be maybe
2-3 orders of magnitude larger than the integration time. Note that
the 'attack' is still instantaneous - if the new meter value is large,
the meter will jump right up there. Then it will slowly fall back
down. I think that's good. Since the decay is exponential it will be
nice and linear on the db scale. All you specify is PPM_DECAY_TIME,
which is the time in seconds until the signal has reached 1/10 of its
original strength (or "is 20 db down" you could say). Default is 0.4

Lastly, PPM_DB_CUTOFF describes the lowest possible decibel value to
use. Any lower than that is just clamped to that value (the scale on
the widget isn't infinite...). Beware that this is a 'db down' value:
0 is maximum intensity, 20 is .1 * maximum and so on. Don't put the
minus sign. Default is 60.0
