HEnquist
FftFixedInOut fails to process
Hi! Thank you very much for your work. I have encountered an issue that I am unsure of whether it is a bug, or am I not understanding something. I am trying to add real-time resampling to my sound processing pipeline using FftFixedInOut. My sound processing model accepts only 48khz samples, and my data is 44.1 khz, and the processing is done in 10 ms chunks. I have initialized 2 resamplers
let u = FftFixedInOut::<f32>::new(44100, 48000, 441, channels).unwrap();
let d = FftFixedInOut::<f32>::new(48000, 44100, 480, channels).unwrap();
And I am having no troubles passing a chunk of length 441, sample rate 44.1khz to my resampler, then to my model. However, I am having troubles processing the output chunk with the downsampler. For some reason, it asks for the input buffer size 640, and output buffer of size 588. I thought that maybe, chunk length of 480 is too small for the resampler, and the next possible values with the same resample ratio as (480, 441) are (640, 588) but then it doesn't make sense that there was no trouble on the upsampling processing, as the operation should be symmetrical. What do you think can be the reason of that behaviour?
Hi! This looks like a bug! There is a problem with the chunk size calculation when downsampling, it gives a larger chunksize that needed. You should be able to get around it for now by asking for a chunksize of 441 (or less, it gets rounded up):
let d = FftFixedInOut::<f32>::new(48000, 44100, 441, channels).unwrap();
The code in question is quite old so the problem must have been there for some time, strange that nobody else has noticed.
PR here: https://github.com/HEnquist/rubato/pull/77
Could you try running your code with branch fix_fft_input_chunksize?
You should be able to get around it for now by asking for a chunksize of 441 (or less, it gets rounded up):
let d = FftFixedInOut::<f32>::new(48000, 44100, 441, channels).unwrap();
That workaround solved it, thanks!
PR here: #77 Could you try running your code with branch
fix_fft_input_chunksize?
Yes, this also solved it. Thank you!