marginal improvement on x86_64 for zero, 5-10% for tiny numbers;
100% time improvement (half the time) on i686 with zero.
#/bin/sh
g++ -x c++ -O3 -ffast-math -o /tmp/a.out - << EOF
#include <stdio.h>
#include <stdlib.h>
#include <cmath>
#include <limits>
static inline float accurate_coefficient_to_dB (float coeff) {
#if 1 // try me
if (coeff < 1e-15) return -std::numeric_limits<float>::infinity();
#endif
return 20.0f * log10f (coeff);
}
int main (int argc, char **argv) {
long long int i;
float f = 0;
if (argc < 3) return -1;
long long int end = atoll (argv[1]);
for (i = 0; i < end; ++i) {
f += accurate_coefficient_to_dB (atof (argv[2]));
}
printf ("%f\n",f);
return 0;
}
EOF
time /tmp/a.out 100000000000 0.0
time /tmp/a.out 100000000000 0.0
time /tmp/a.out 100000000000 0.0
The peak meter needs to withstand various test-signals
without visual jitter (in particular 1kHz sine) regardless
of settings (period-size, sample-rate, custom fall-off).
This needs to be done in sync (and not by a random non-rt
‘smoothing’ thread).
On the downside this voids the ‘visual smoothing’ particularly
with large buffersizes - but then again exactly this “always
fall-off no matter what [the next real data will be]” is the
problem.
One the upside, there’s one less high-frequency (100Hz) thread
(Yay!) PS. it probably never worked on windows, anyway.
Only peak-meters are affected by his change.
K-meters, IEC I/II and VU were never visually smoothed.
The processor-box GUI only allows to move the
custom meter position between trim and main_out/panner.
Previously an initial switch from In -> custom or Out -> Custom
left the meter at a position that can otherwise not be reached
by manually repositioning the custom meter.
This works around abysmal performance (~.15ms) of
boost::function and boost::bind (in PBD::Signal).
The overall load is probably higher but the realtime
thread remains unaffected.
