Re: [LAD] Suitable peak/RMS/etc. data for UI metering

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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev