Closed f0k closed 1 week ago
Thanks @f0k! We have pretty comprehensive tests for the extra time stretch options, but there's a gap in the test coverage; it seems this happens with any sufficiently-large buffer (5 seconds at 44.1kHz does it, but 0.5 seconds at 22050Hz does not).
I can replicate this locally and should be able to put up a quick patch.
This appears to be a bug in the underlying Rubber Band library we use for time stretching; the alloca
function is called in a loop, but its allocations are not cleared until the end of the function (by design), resulting in a stack overflow if the input is long enough.
I'll send a PR over to Rubber Band to solve the underlying issue, but I think we can get around this in Pedalboard by calling study
in a loop and cap the maximum number of samples provided at once.
Thanks a lot @psobot for following up on this and even sorting out the problem for rubberband! :detective:
All parameter combinations for
time_stretch()
that havehigh_quality=False
anduse_time_domain_smoothing=True
cause a segfault. Example:Saving as
ts.py
and runninggdb --args python3 ts.py
, this is the beginning of the backtrace:I did not investigate further. This is on pedalboard 0.9.6.