25 Jul
2011
25 Jul
'11
5:43 p.m.
Hello,
A new/upcoming LV2 extension (from Lars Luthman) includes facilities for
sending host-calculated metric data for audio ports to a UI, for
metering and such. This is intended as a sane replacement for the
currently used kludge of having plugin control output ports provide this
information.
So, more DSP-minded folks, my question is: what data is required, and is
a reasonable compromise between overhead and expressiveness? The
current revision has the following:
/**
A data type that is used to pass peak and RMS values for
a period of audio data at an input or output port to an
UI, using port_event. See the documentation for
pui:floatPeakRMS for details about how and when this
should be done.
*/
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;
Thanks,
-dr
25 Jul
25 Jul
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
7:45 p.m.
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:
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.
*/
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.
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
26 Jul
26 Jul
6:17 a.m.
On Mon, Jul 25, 2011 at 12:03 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Mon, Jul 25, 2011 at 11:43:14AM -0400, David
Robillard wrote:
Hi Fons,
I'm interested in what you're saying about RMS metering. Could you give me
specifics or point me to a reference? I can't find anything by googling.
What sort of low pass filter is used for audio metering, for example?
Jeremy
*/
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
8:33 a.m.
On Tue, Jul 26, 2011 at 12:17:18AM -0400, Jeremy Salwen wrote:
I'm interested in what you're saying about RMS
metering. Could you give me
specifics or point me to a reference? I can't find anything by googling.
What sort of low pass filter is used for audio metering, for example?
All sorts of, depends on the application. For a meter, the filter
determines how signal level variations are displayed. Simply put
how 'fast' the meter reacts to them, but there is more to it.
For example a second order filter will allow the meter to react
faster to a sudden level change while being less sensitive to
randon variations than a first order one with the same 'speed'.
Very few audio meters use true RMS, but you have the same issues
with e.g. meters that use absolute value instead, e.g. a VU. In
a 'real' VU, the filtering is done by the ballistics of the meter,
which are closely specified and quite different from those of normal
voltage or current meters. They are equivalent to a second order
lowpass filter, so if you want to emulate a VU in software you
have to implement that filter.
Just summing over N samples as in the LV2 proposal is a lowpass
filter as well, but not a very good one. It has zeros at all
multiples of sample_rate / N, and significant gain in between.
So for example if the sample rate is 48 kHz, and N is 480, the
meter will not show level variations with a frequency of 100 Hz,
200 Hz, etc, but it will be quite sensitive for others. And worse,
if N is the processing period, that means that the meter will show
different results for the same signal, depending on which Jack
period you happen to use. It doesn't affect steady signals of
course, but few musical signals have constant amplitude.
Ciao,
--
FA
5310
days inactive
5311
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
David Robillard -
Fons Adriaensen -
Jeremy Salwen