-
-
Save andr-ew/f19575fe91773c5feb9f7e1d765015d9 to your computer and use it in GitHub Desktop.
-- interpolation branch benchmarking | |
interp = false | |
rate = 8 | |
function init() | |
boundaries={ | |
{1,1,80}, | |
{1,82,161}, | |
{1,163,243}, | |
{2,1,80}, | |
{2,82,161}, | |
{2,163,243}, | |
} | |
local loop_length = 0.5 * rate | |
softcut.reset() | |
audio.level_cut(1) | |
audio.level_adc_cut(1) | |
audio.level_eng_cut(1) | |
audio.level_tape_cut(1) | |
softcut.buffer_clear() | |
for i=1,6 do | |
softcut.enable(i,1) | |
softcut.level_input_cut(1,i,0.5) | |
softcut.level_input_cut(2,i,0.5) | |
softcut.buffer(i,boundaries[i][1]) | |
softcut.level(i,0.1) | |
softcut.pan(i,0) | |
softcut.rate(i,rate) | |
softcut.loop(i,1) | |
softcut.loop_start(i,boundaries[i][2]) | |
softcut.loop_end(i,boundaries[i][2]+loop_length) | |
softcut.level_slew_time(i,0.2) | |
softcut.rate_slew_time(i,0.2) | |
softcut.recpre_slew_time(i,0.1) | |
softcut.fade_time(i,0.2) | |
softcut.rec_level(i,0.5) | |
softcut.pre_level(i,0.5) | |
softcut.phase_quant(i,0.025) | |
softcut.post_filter_dry(i,0.0) | |
softcut.post_filter_lp(i,1.0) | |
softcut.post_filter_rq(i,1.0) | |
softcut.post_filter_fc(i,20100) | |
softcut.pre_filter_dry(i,1.0) | |
softcut.pre_filter_lp(i,1.0) | |
softcut.pre_filter_rq(i,1.0) | |
softcut.pre_filter_fc(i,20100) | |
softcut.position(i, boundaries[i][2]) | |
softcut.play(i,1) | |
softcut.rec(i,1) | |
if interp then | |
softcut.interpolation(i, interp) | |
end | |
end | |
end |
so the difference in CPU usage is much higher at a high rate, but I think that's entirely avoidable
here I'm checking the interpolation mode for every sample that gets written to the buffer, but instead i can just call it for every input sample & run a few alternate functions
ok, results after these changes
sc-interpolation-mode-optimize-write branch, rate = 1
sc-interpolation-mode-optimize-write branch, rate = 8
(I'm rerunning the main branch tests here because I wasn't careful about keeping the frequency of cuts consistent the first time (I was changing rate
w/o scaling by loop_length
)
(little surprising, but I did recompile & run each test a second time just to be sure
-
there are issues with the logic behind the change. please think about it a little more.
-
top
is an inadequate tool for measuring audoi DSP load with this precision. please read about it. (the TL/DR:top
does some interpolation and windowed averaging and stuff, but ultimately computes load on borders of 10ms time slices. 10ms is longer than an audio block, but not by much..)
on norns, the best way to evaluate this is to simply crank the rates up (or etc) and look for buffer underruns (reported by JACK in the norns-crone
service log). off norns, you can use real profiling tools like valgrind
or your favorite IDE. (which might have e.g. a graphic interface laid over proc
.)
first set of results from
top
stock norns, playing
TAPE
into softcutmain branch, rate = 8
sc-interpolation-mode branch, rate = 8
sc-interpolation-mode branch, rate = 1
main branch, rate = 1