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

David Robillard d at drobilla.net
Mon Jul 25 17:45:03 UTC 2011


On Mon, 2011-07-25 at 16:03 +0000, Fons Adriaensen wrote:
> 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.

The only real application here is widgets in a plugin UI.  A very basic
and generic solution should be fine (but should be as accurate/useful as
possible, of course).  Basically we're shooting for enough information
to make a meter go boink in an informative-enough way.

Sending updates for a given block of audio is an inherent requirement.

> This means that:
> 
> * period_start: can be useful.
> * period_size: should be defined as the number of samples processed 
>   since the last event.

I believe the intent here was to tolerate skipped updates, so the update
is for the block [period_start .. period_size]

> * The definition of RMS as you provide it should be dropped.

What should it be replaced with?  Or, for the basic use case[1]
mentioned would even just peak be enough?  Ardour, IIRC, just uses
peaks, and presumably it's metering is sufficient, so that implies maybe
RMS can just go (I do not know if Lars added it for a specific reason).

If RMS isn't really useful for basic metering, I'd rather just drop it
entirely, since it's expensive.  Granted, in this day and age the
expense of measuring whatsoever (i.e. iterating over the buffer)
probably dwarfs whatever math you're doing in the process, but still.

Thanks,

-dr

[1] Plugin/UI authors, feel free to pitch in with any others





More information about the Linux-audio-dev mailing list