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.
Due to the change to use a 64bit timeline (int64 as opposed
to previously [unsigned] pframes_t) many cases special to tape-tracks
no longer work.
e.g. region->length() can returns -1, rather than INT64_MAX.
which breaks ‘overlap’ in Evoral::Coverage. which in turn
breaks tape track’s use of ::find_next_region().
This commits begins the slow process to move away from relying
on integer overflow to wrap negative numbers for tape tracks and
restores basic functionality.
Still various edge cases pertaining tape tracks remain. particularly
when changing the session start-time and moving destructive regions.
