25 Jul
2011
25 Jul
'11
6:03 p.m.
On Mon, Jul 25, 2011 at 11:43:14AM -0400, David Robillard wrote:
*/
typedef struct _LV2_PUI_Peak_RMS_Data {
/**
The start of the measurement period. This is just a
running counter that must not be interpreted as any
sort of global frame position. It should only be
interpreted relative to the starts of other
measurement periods in port_event() calls to the same
plugin instance.
This counter is allowed to overflow, in which case it
should just wrap around.
*/
uint32_t period_start;
/**
The size of the measurement period, in the same units
as period_start.
*/
uint32_t period_size;
/**
The peak value for the measurement period. This
should be the maximal value for abs(sample) over all
the samples in the period.
*/
float peak;
/**
The RMS value for the measurement period. This should
be the root mean square value of the samples in the
period, equivalent to sqrt((pow(sample1, 2) +
pow(sample2, 2) + ... + pow(sampleN, 2)) / N) where N
is period_size.
*/
float rms;
} LV2_PUI_Peak_RMS_Data;
In all cases I know of the RMS value required for metering, dynamics
processing, etc. is *not* the average over a period, nor over any other
rectangular window. It is the result of applying a specific lowpass
filter on the squared samples, which one depends on the application.
This means that:
* period_start: can be useful.
* period_size: should be defined as the number of samples processed
since the last event.
* The definition of RMS as you provide it should be dropped.
Ciao,
--
FA