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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev