Open to cheap FeedbackCombFilter?

[JackCA]

The recent change to use ConvolverNodes in Freeverb and JCReverb has lead to greater quality in those nodes, however; as noted (#637 #637) it's also introduced some performance issues on lower-powered devices.

In order to avoid some pretty bad audio glitches on mobile Safari, I've done the following in my project:

• introduced the non-convolver-based FeedbackCombFilter back in to my project and named it FeedbackCombFilterCheap
• created a LowpassCombFilterCheap that uses that
• created JCReverbCheap and FreeverbCheap that use the above two nodes in place of the non-cheap versions

Would that helpful to pull into Tone.js? Otherwise, the above solution may help other folks looking for a workaround

[tambien]

How well does Reverb work (or not work) on iOS current? I haven't tested extensively on iOS. I think it'd be good to get any metrics (or even anecdotal data) on the difference in performance between Reverb and the FeedbackCombFilter-based reverbs. The route that you're suggesting would add 6 additional classes (since it would also require a PluckSynthCheap) and their test files, so it'd be good to know the benefit before committing to that route.

To be honest, i'd rather figure out ways to optimize FeedbackCombFilter and make it work well on iOS since the current implementation is more "correct" (e.g. the delayTime does not need to be aligned to 128 samples), future-proof and easier to maintain than having two sets of the same object.

It seems like switching the FeedbackCombFilter's worklet processor from a-rate to k-rate really helps in my testing on Safari (haven't checked on iOS yet though). I'll push that code soon if it seems to work well. So i wonder if there are other ways to optimize that code to make it work better in its current form before replacing it.

[JackCA]

on midi.city I would hear crackling on an iPhone 11 Pro and when making the above switch, that issue (for the most part) has gone away. That's a top-end model so I can only imagine that it's exacerbated on lower-end devices.

I agree that a better solution would be to optimize the nodes themselves but unfortunately, without you having access to a real iOS device, I don't know how you're going to benchmark it or verify whether or not regressions exist.

In the meantime, if you create a demo/benchmark, I'd happy to get pinged and test things for you though.

Is there a way to quantitatively measure the performance of these nodes in Safari?

[tambien]

I guess i was specifically asking about the performance comparison between the old Tone.Freeverb and the current Tone.Reverb. Can you try replacing Freeverb with Reverb in midi.city and see if that crackles also? I'm open to the potential that Freeverb and JCReverb have outlived their usefulness

I've read that feedback delay networks are hypothetically more performant than Convolution-based nodes, but that hasn't been my experience where the convolution-based nodes seem to perform just as well.

[tambien]

So here's a not very scientific test which compares the old (version 13.8.25) Tone.Freeverb to Tone.Reverb. You can alter the count and useFreeverb variables to test out the performance. For me, Tone.Reverb on Chrome lasts just slightly longer before crackling or going silent than Tone.Freeverb and on Safari Tone.Reverb works much better than Tone.Freeverb.

That is to say that, i'm not sure there is such a big enough performance benefit of the FeedbackCombFilter-based reverbs over Convolution-based to justify all of the overhead of maintaining two versions of each of the classes.

[JackCA]

Sorry for the delayed response here.

That test does indeed seem to prove that my assumption about the convolution nodes was incorrect. Apologies for the misdirect.

I believe what I was experiencing was related to the perf issues I was seeing with #686.

Thanks! ☮️