Add resample support via ssrc (libresample)

[gnif]

This patch set rewrites the common processing code to add resample support if it is required. Things of note with this patch set:

• Run-time memory allocation/deallocation has been replaced with ringbuffers
• RnNoise has been altered slightly to support a ringbuffer avoiding additional memory copies
• Resample should be bypassed for 48KHz, but this is untested.

[werman]

Overall it looks good, I didn't look deep into it just glanced at it, I'll look better later. Also could you squash the commits because I don't think all this history is needed

[gnif]

That's it, relevant commits squashed together. I kept RnNoise alterations separate. It might be an idea to suggest these upstream, but I will leave that up to you if you wish to pursue that.

[werman]

Thanks! Could you allow me to change the branch? I would like to push my changes. Or here are they: feature/resample, you can change the branch yourself.

Also there is one issue - the performance. I don't have exact numbers but I can see in htop that pulseaudio starts using around 30% of core while before the changes it used 5%. Since I have 44100Hz sample rate resampling is working but seems costly. So we need to think what to do about it because without resampling rnnoise can cope with slight sampling difference from my observations.

[gnif]

I will pull that patch into my repo, I have also noted that on larger buffer sizes it's doing strange things, ie. as an Audacity plugin. As for CPU usage, the resampler has quality settings, where I selected the best mode possible, however as this is for speech is is likely way overkill and can be dropped down. I will do some experimentation and see.

Edit: Actually I will use your branch as my upstream and rebase on your code.

[gnif]

I have spend considerable time on this today and as it currently stands I can not see how this will ever function correctly for programs that supply large buffers like Audacity,

At the very least the LADSPA interface expects the same number of samples out as were sent in, and since Audacity operates in 512KB blocks, this number is not a multiple of the ReNoise frame size of 480 ((512*1024)/480 = 1092.26666667), which makes this filter practically useless for such applications.

I am not sure how to proceed and my time allotment for this task is up I am sorry

[theglobe]

I have spend considerable time on this today and as it currently stands I can not see how this will ever function correctly for programs that supply large buffers like Audacity, At the very least the LADSPA interface expects the same number of samples out as were sent in, and since Audacity operates in 512KB blocks, this number is not a multiple of the ReNoise frame size of 480 ((512*1024)/480 = 1092.26666667), which makes this filter practically useless for such applications. I am not sure how to proceed and my time allotment for this task is up I am sorry

I've seen that Davinci Resolve gives 480 bytes buffers in sound design mode but switches between two other sizes, don't remember which, one about 600 and one small, when editing the timeline and the plugin handles these. I guess 480 was chosen because of the sample rate 48000 kHz, or? If we want to use the rnn properly for other sample rates I think we must adjust and train it accordingly for each sample rate.

…

[werman]

At the very least the LADSPA interface expects the same number of samples out as were sent in, and since Audacity operates in 512KB blocks, this number is not a multiple of the ReNoise frame size of 480 ((512*1024)/480 = 1092.26666667), which makes this filter practically useless for such applications.

I am not sure how to proceed and my time allotment for this task is up I am sorry

That doesn't sound good, just a wild idea - either pad the last frame with silence or pad it on the left with data from previous frame. I probably should try to use ladspa plugin with Audacity.

I guess 480 was chosen because of the sample rate 48000 kHz, or?

Yes.

If we want to use the rnn properly for other sample rates I think we must adjust and train it accordingly for each sample rate.

I do believe that it shouldn't be necessary to retrain the network because what is the REAL difference for neural network between sample rates - I don't think there is much.

[gnif]

I do believe that it shouldn't be necessary to retrain the network because what is the REAL difference for neural network between sample rates - I don't think there is much.

I think you will find that it actually does matter, there is a fork of RnNoise called RnNoise-nu which attempts to implement variable sample rates, both the author of RnNoise and RnNoise-nu have agreed that a retrain is required.

See: xiph/rnnoise#39

[werman]

I do believe that it shouldn't be necessary to retrain the network because what is the REAL difference for neural network between sample rates - I don't think there is much.

I think you will find that it actually does matter, there is a fork of RnNoise called RnNoise-nu which attempts to implement variable sample rates, both the author of RnNoise and RnNoise-nu have agreed that a retrain is required.

See: xiph/rnnoise#39

That's unfortunate.

[werman]

I took stab at resampling, but nothing good came out. I see no point in implementing resampling. At the end I ended adding a stern warning to use only 48KHz. It's a already a standard sampling rate on all systems.